AP-side payouts · multi-rail · one ledger

Vendor payment processing — pay every vendor, every rail, on one API.

topropay's payout side runs ACH, SEPA, push-to-card and stablecoin behind the same unified API the inbound side uses. Hosted vendor onboarding, dual-control approvals, returns handling and one ledger across receipts and payouts.

Book a payouts review Read the API docs
merchant ACH SEPA Push card Stablecoin vendor A vendor B vendor C vendor D one merchant · 4 rails · many vendors
Per-vendor rail policy · returns auto-handled.
ACH · SEPA · Push-to-card · Stablecoin
vendor payout rails on one API
Multi-vendor
split-pay on the same merchant record
Approvals
two-eyes / dual-control on every batch
1 ledger
inbound receipts + outbound payouts reconciled together

Key benefits

Why this approach to vendor payment solutions pays off

Four properties that show up the moment AP stops bouncing between bank files, scheme portals and reconciliation spreadsheets.

  1. One API for every vendor payout rail

    ACH (US), SEPA Credit Transfer (EU), Faster Payments and Bacs (UK), push-to-card via Visa Direct / Mastercard Send, plus licensed-partner-delivered stablecoin payouts. The merchant's AP system integrates one endpoint and picks the rail per vendor.

  2. Vendor onboarding without the spreadsheet

    Hosted vendor onboarding collects bank details, beneficial-ownership, tax forms (W-9 / W-8BEN / equivalent) and a signed ACH vendor payment form. The merchant doesn't email PDFs around; vendors fill the hosted form once.

  3. Multi-vendor split-pay on inbound

    Marketplaces that take a single buyer payment and need to split it between multiple sellers run multi vendor payment gateway logic on the same merchant record. The split rules live in the dashboard; settlement reconciles per seller.

  4. Dual-control approvals & audit log

    Every payout batch routes through configurable approval policies (single, dual or N-of-M). Every step — submitted, approved, sent, settled, returned — logged with actor identity, timestamp and IP. Audit-export ready for SOC and ISAE attestations.

How vendor payment systems run underneath

From vendor onboarding to settled payout in six steps

What actually happens between the moment finance imports a payout batch and the moment the vendor's account is credited.

  1. 01

    Onboard the vendor

    Vendor receives a hosted onboarding link. They submit bank details, tax forms and KYC. Bank-account verification runs via micro-deposits or instant verification (Plaid-style) per region.

  2. 02

    Pick the payout rail

    Per-vendor configuration picks the right rail — ACH for US bank account, SEPA for EU IBAN, push-to-card for instant payout, stablecoin for cross-border crypto-native counterparties.

  3. 03

    Build the batch

    The merchant's AP system or finance team builds a batch — by API import, dashboard upload or scheduled rule. Each line carries amount, currency, vendor ID and remittance reference.

  4. 04

    Route through approvals

    Configurable approval policy gates the batch — finance prepares, controller approves, CFO signs off, optional segregation of duties enforced per role.

  5. 05

    Send to rail

    Approved batches submit to the chosen rail. ACH cuts batched by NACHA window; SEPA SCT submits to the bank; push-to-card hits the scheme switch in near-real-time; stablecoin broadcasts on the configured chain.

  6. 06

    Reconcile inbound + outbound

    Inbound receipts and outbound vendor payments normalise into one ledger, tagged with vendor ID, rail, batch ID and currency. Returns and reversals (NACHA R-codes, SEPA SCT-Inst rejects) feed back automatically.

Main use cases

Where this vendor payment gateway shape earns its keep

Six recurring merchant shapes that benefit from one platform across inbound receivables and outbound vendor payouts.

  • MP

    Multi-vendor marketplaces

    Marketplaces pay sellers per order or per cycle. multi vendor payment gateway logic splits buyer receipts across sellers based on dashboard-configured rules and pays them on their preferred rail.

  • Gig

    Gig-economy platforms

    Platforms paying drivers, couriers, tutors or freelancers daily / weekly. Push-to-card delivers near-instant payouts; ACH is the fallback for vendors who prefer bank deposit.

  • B2B

    B2B AP automation

    Mid-market merchants paying 50–5000 vendors per cycle. Hosted onboarding plus batched ACH replaces the manual vendor-form-and-spreadsheet workflow.

  • Trav

    Travel & hospitality payouts

    Hotel and tour operator payouts to property owners, guides and local partners. Multi-currency settlement and per-vendor rail policy handle the international long-tail.

  • Aff

    Affiliate and creator payouts

    Affiliate networks and creator platforms paying thousands of small payouts per month. Per-payout-minimum, threshold-based batching and tax-form collection on file.

  • Sub

    Subscription-billing rebates and refunds

    Subscription merchants who issue mass refunds or loyalty rebates as ACH credits or push-to-card payouts — same engine, same ledger.

Platform features

Capabilities behind the multi vendor payment gateway side of topropay

Twelve capabilities the platform ships once and reuses across every vendor payout rail — the primitives that make AP feel like one product.

  • Hosted vendor onboarding

    Branded, vendor-facing onboarding form — bank, tax (W-9 / W-8BEN), KYC; per-region requirements wrapped.

  • Signed ach vendor payment form

    NACHA-compliant authorisation captured at onboarding; mandate ID stored against the vendor record.

  • Per-vendor rail policy

    Default rail per vendor; merchant override per batch; vendor self-service to change their own preference.

  • Batch builder & schedule

    Build batches manually, via CSV upload, via API import or via scheduled rules (e.g. every Thursday for prior-week earnings).

  • Dual-control approvals

    Single, dual or N-of-M approval policies; segregation of duties enforced per role; configurable per batch size threshold.

  • Multi-vendor split-pay

    Per-line split rules tied to inbound buyer authorisations; reconciliation per vendor across split batches.

  • Push-to-card payouts

    Visa Direct / Mastercard Send via partner connectivity; near-instant payout to a vendor's debit card.

  • Stablecoin payouts

    USDC / USDT / DAI via licensed partner crypto gateways; AML / KYC inherited from the partner.

  • Returns & reversal handling

    NACHA R-codes, SEPA SCT-Inst rejects and on-chain failures feed back into the vendor record with reason codes.

  • Tax-form collection

    W-9 / W-8BEN / W-8BEN-E / W-8IMY / 1099 prep where US merchant is the payer; equivalent EU forms per region.

  • Audit-grade event log

    Every state transition logged with actor identity, IP, timestamp; export for SOC / ISAE attestations.

  • Unified reconciliation

    Inbound buyer receipts + outbound vendor payouts in one ledger tagged by vendor, rail, batch, currency and reason code.

Industry relevance

Vendor payouts for licensed EU, UK, APAC and LATAM merchants

topropay's vendor-payout posture targets licensed merchants paying vendors across Europe, the UK, APAC and LATAM — marketplaces splitting per seller, gig-economy platforms paying drivers and couriers, B2B AP automation in the mid-market, travel and hospitality payouts to property owners and guides, and affiliate / creator payouts at scale.

Trust & compliance

Compliance posture across every vendor payout rail

One audited environment for the orchestration layer; rail-specific posture (NACHA / SEPA / scheme programmes) on the payout side.

PCI DSS Level 1
Card data (for push-to-card payouts) captures into the platform vault; PAN never lands in merchant systems.
NACHA mandate handling
ACH vendor mandates captured, retained per scheme rules, and surfaced for audit on demand.
SEPA SCT & SCT Inst
SEPA Credit Transfer and SCT-Inst payouts under PSD2-aligned bank connectivity; mandate retention per scheme rules.
AML & sanctions screening
Vendor onboarding includes sanctions screening; high-risk vendor pattern detection on outbound flows.
Tax-form retention & 1099 prep
US tax-form data retained per IRS rules; 1099-NEC and 1099-MISC prep for merchants who are the payer; equivalent EU controls per region.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope.

Ready to consolidate payouts

Pay every vendor through one platform.

A 30-minute payouts review covers the rails relevant to your vendor base, the approval workflow that fits your finance structure, and a sandbox you can test against before any commercial commitment.

Book a payouts review Read the docs

Frequently asked

Buyer questions about vendor payment processing on topropay

Definitions, multi-vendor split mechanics, returns handling, dual-control approval workflow and the practicalities of running AP through one platform.

  1. 01

    What does vendor payment processing on topropay cover end-to-end?

    Vendor payment processing covers the full AP-side flow: vendor onboarding (bank details, tax forms, KYC), per-vendor rail selection (ACH / SEPA / push-to-card / stablecoin), batch building, dual-control approvals, rail submission, returns / reversals handling, and reconciliation against inbound buyer receipts in one ledger.

  2. 02

    Which vendor payment solutions ship out of the box?

    Vendor payment solutions out of the box include hosted vendor onboarding, ACH / SEPA / Faster Payments / Bacs payouts, push-to-card via Visa Direct / Mastercard Send, optional stablecoin payouts via licensed partner crypto gateways, dual-control approvals, batch scheduling, returns handling and tax-form collection.

  3. 03

    How do vendor payment systems differ from regular AP software?

    Vendor payment systems on topropay differ from regular AP software by combining the rails themselves with the AP workflow. The merchant doesn't connect a separate ACH gateway, separate SEPA bank file generator and separate push-to-card service — they're all unified behind one API, with one vendor record and one ledger across rails.

  4. 04

    Is there a dedicated vendor payment gateway?

    The vendor payment gateway on topropay isn't a separate product — it's the same orchestration platform exposing payout endpoints. The merchant integrates one API for both inbound buyer acceptance and outbound vendor payouts; the rails sit with licensed partner banks and acquirers.

  5. 05

    Does topropay support an ach vendor payment form for new vendors?

    Yes. The hosted vendor onboarding flow captures a NACHA-compliant ach vendor payment form — bank account, routing number, account holder details and a signed authorisation. The mandate ID is stored against the vendor record and surfaced for audit on demand.

  6. 06

    What does the multi vendor payment gateway pattern look like for a marketplace?

    The multi vendor payment gateway pattern works like this on topropay: a single buyer authorisation lands; the routing engine splits the cleared amount per seller per the dashboard-configured split rules; outbound payouts queue up per seller on the seller's preferred rail; reconciliation rolls up per seller in the same ledger.

  7. 07

    How are vendor payout fees structured?

    Vendor payout fees are typically per-payout for ACH and SEPA (a fixed amount), per-payout-plus-percentage for push-to-card and stablecoin (because the underlying rails charge that way). Returns / reversals are passed through at the rail's cost; refunds against original vendor payouts follow the original-rail rules.

  8. 08

    Can vendors be paid in multiple currencies?

    Yes. Per-vendor currency configuration picks the payout currency; multi-currency settlement is supported where the partner bank holds the relevant accounts. Conversion at payout happens at the partner-bank rate disclosed in the dashboard before approval.

  9. 09

    What returns / reversal codes does the platform handle?

    NACHA R-codes (R01 — Insufficient Funds, R03 — No Account, R04 — Invalid Account Number, R07 — Authorization Revoked, R10 — Customer Advises Not Authorized, etc.) feed back into the vendor record automatically. SEPA SCT-Inst rejects and stablecoin on-chain failures are similarly captured.

  10. 10

    How does the approval workflow work for large batches?

    Approval workflow is configurable — for example, batches under $10,000 require single approval; batches between $10,000 and $100,000 require dual approval; batches above $100,000 require CFO sign-off. Roles and limits are dashboard-editable; segregation of duties (preparer ≠ approver) enforced per policy.

  11. 11

    Can the platform replace our existing AP automation tool?

    The platform can replace the payment side of AP automation (rail connectivity, vendor onboarding, batch payouts). It typically pairs with — rather than replaces — invoice-management tools like Bill.com, Tipalti's invoice features, or in-house systems. Connectors push approved invoices into the topropay batch builder.

  12. 12

    Is push-to-card available for all vendors?

    Push-to-card via Visa Direct / Mastercard Send is available where the vendor holds an eligible debit card and the partner-acquirer has activated the scheme programme for the merchant. Coverage is broadest in the US, growing in EU and APAC. ACH is the universal fallback.

  13. 13

    How does the platform handle 1099 prep for US vendors?

    For US merchants who are the payer of record, 1099-NEC and 1099-MISC prep runs off the vendor record (W-9 captured at onboarding) and the year's payout total. The platform produces the 1099 file ready for IRS submission and the recipient copy ready to send to the vendor.

  14. 14

    Can resellers / PSPs offer vendor payment processing to their downstream merchants?

    Yes. PSPs and resellers inherit the payout rails and configure independent vendor records, approval policies and rail preferences per downstream merchant. The PSP keeps the merchant relationship; the platform handles the rail-side execution.

  15. 15

    What kinds of vendor payouts are out of scope?

    Out-of-scope payouts include those tied to unlicensed gambling or grey-market verticals, adult-content payouts where the underlying merchant isn't licensed, and any payment that would require topropay or its partner banks to break sanctions / AML rules. The onboarding flow filters these out before any volume starts.

Related

Related on the topropay platform