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.completedon settlement,payment.failedon rejection,payment.disputedon chargebacks / ACH returns. - Payouts:
payout.created→payout.updated(in transit) →payout.paidorpayout.failed. A settled ACH payout that the receiving bank later sends back firespayout.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.
// 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:
| Rail | Destination | Speed |
|---|---|---|
| card | Debit card (push-to-card) | Typically minutes (card-dependent — verify with an account check) |
| ach | Bank account | 1–2 business days |
| rtp | Bank 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 number | Brand | Behavior |
|---|---|---|
| 5333619503715702 | Mastercard | Debit, immediate funds availability |
| 5113400335932393 | Mastercard | Debit, next-day funds availability |
| 4916900573237001 | Visa | Debit, immediate funds availability |
| 4729260119078493 | Visa | Debit, 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.