Debit & Payouts

Accept debit payments and send money on Paysio Debit & Payouts.

Paysio Debit & Payouts is a US-only processor for money-in (debit card pulls and ACH debits) and money-out (push-to-debit-card, ACH, and real-time RTP payouts). It uses the same V1 API as other Paysio workspaces — tokens, customers, payment methods, charges, transactions, and checkout sessions all work — plus a dedicated Payouts API for sending money. All amounts are USD, in cents.

Asynchronous settlement

Every money movement on Debit & Payouts is asynchronous. The API accepts the request and returns immediately with a non-final status — charges return "status": "pending_settlement" and payouts return "status": "pending". The terminal state arrives via webhooks:

  • Charges: payment.completed on settlement, payment.failed on rejection, payment.disputed on chargebacks / ACH returns.
  • Payouts: payout.createdpayout.updated (in transit) → payout.paid or payout.failed. A settled ACH payout that the receiving bank later sends back fires payout.returned.

Configure a webhook endpoint before going live — polling GET /transactions/:id or GET /payouts/:id works but webhooks are the intended integration. See Webhooks for full payload examples.

This shapes the ideal buyer experience too: don't render a success screen off the 201 — settlement typically lands within seconds. Show a brief "confirming your payment" state and let payment.completed / payment.failed decide the outcome. Paysio's hosted checkout does this out of the box: the confirmation page holds a live confirming state until the charge settles, then reveals the receipt — or shows the decline reason with a retry back to the checkout. It's on by default, controlled per workspace under Settings → Checkout → Live payment confirmation.

CVC is required for every card charge — and never stored

The card network requires the security code on every debit pull, even when charging a saved payment method. But this does not mean you collect it yourself: the mountCardInputs() secure fields already include a CVC input, and the CVC rides inside the ptok_ token — so token charges need no cvc param and no extra CVC field in your UI. Only when charging a saved card later (vault charge) do you collect the CVC again and pass it as cvc in the POST /charges body. Paysio never stores the CVC.

Because of this, POST /subscriptions is not available over the API on Debit & Payouts workspaces. Hosted Checkout Sessions fully support recurring products.

Money-in: card pulls and ACH debits

Charge debit cards exactly like any other workspace: tokenize with paysio.js (secure hosted fields) or save a card to a customer, then call POST /charges. To debit a bank account instead, pass rail: "ach" with a saved bank-account payment method or inline routing/account numbers — no CVC needed for ACH.

JavaScript
// Vault charge (saved card) — cvc required
POST /charges
{
  "customer_id": "customer-uuid",
  "amount": 2999,
  "cvc": "123"
}

// ACH debit from a saved bank account
POST /charges
{
  "customer_id": "customer-uuid",
  "payment_method_id": "instrument-id",
  "amount": 2999,
  "rail": "ach"
}

// ACH debit with inline bank details
POST /charges
{
  "customer_id": "customer-uuid",
  "amount": 2999,
  "rail": "ach",
  "routing_number": "021000021",
  "account_number": "1234567890"
}

Refunds are issued as reverse payouts back to the original instrument (POST /transactions/:id/refund); voids cancel a still-pending pull. See Charges for the full parameter list.

Bank account payment methods

Customers can hold bank accounts alongside cards. Save one with type: "bank_account" on POST /customers/:id/payment-methods — it can then be debited (rail: "ach" charges) or paid out to (ACH / RTP payouts).

POST /customers/:id/payment-methods
{
  "type": "bank_account",
  "routing_number": "021000021",
  "account_number": "1234567890",
  "account_type": "checking"
}

Money-out: payouts

Send money from your balance to a customer's debit card or bank account with POST /payouts. Three rails:

RailDestinationSpeed
cardDebit card (push-to-card)Typically minutes (card-dependent — verify with an account check)
achBank account1–2 business days
rtpBank account (TCH or FedNow)Seconds, 24/7 — bank must support RTP

Fees are exclusive: the amount you pass is what the recipient receives, and the payout fee is charged on top — your balance drops by amount + fee. Payouts are reserved against your available balance immediately, fee included (check it with GET /balance), and a payout with insufficient balance is rejected with a 400.

Account checks

Before sending a payout, POST /account-checks tells you whether a card can receive push-to-card funds (and how fast), or which RTP networks a bank supports by routing number. ACH has no pre-flight check — an ineligible account surfaces later as an ACH return. See the Payouts reference.

Sandbox testing

Use a sk_test_ / pk_test_ key. These test cards exercise the different settlement behaviors:

Card numberBrandBehavior
5333619503715702MastercardDebit, immediate funds availability
5113400335932393MastercardDebit, next-day funds availability
4916900573237001VisaDebit, immediate funds availability
4729260119078493VisaDebit, next-day funds availability

Use any future expiry and any CVC. To test the bank_account type (ACH / RTP rails), use the sandbox routing number (ABA) 021000021 with any account number (4-17 digits). Credit (non-debit) cards are rejected for payouts — use an account check to confirm eligibility.