Commerce Hub

/

Straight-Through Disbursement

Straight-Through Disbursement lets a platform submit a payout to a recipient without creating and activating a party for that recipient. Payouts are funded from the proceeds of the platform's own card acceptance activity.

Acceptance proceeds establish a dedicated payout funding balance. The platform submits a single, self-contained payout request that carries the recipient details and an encrypted payment source, and the payout is executed to the recipient's card through push-to-card rails. No party is created or activated for the recipient as a precondition of payment.

Straight-Through Disbursement is a Payouts capability. It is distinct from Onboard Participant flows, which create and activate a party for a seller or buyer, and from platform settlement configuration completed during implementation.

Why Straight-Through Disbursement Matters

Platforms that pay large numbers of consumers often cannot require every recipient to complete an onboarding journey before receiving funds, and managing a separate prefunding process adds cost, delay, and reconciliation effort. Straight-Through Disbursement connects money-in and money-out within one integration.

Straight-Through Disbursement helps platforms:

Pay recipients without creating and activating a party for each one
Fund payouts directly from card acceptance proceeds rather than separate prefunding
Deliver funds quickly to eligible cards through push-to-card rails
Maintain end-to-end traceability from acceptance through payout and settlement
Scale to high-volume consumer disbursement use cases through a single integration

Payout Lifecycle

The lifecycle spans configuration, funding, payout, and settlement. Payout activity is API-driven, and lifecycle outcomes are returned as status updates.

Stage	Description
Configuration	The platform is configured at the merchant level, including straight-through processing without party creation and applicable funding transaction behavior.
Funding	Card acceptance proceeds are captured and used to establish the platform's payout funding balance.
Secure card data	The platform encrypts the recipient card data with a Multi-Use Public Key (MUPK) to produce encryptionData.
Payout request	The platform builds the payment source and submits a self-contained payout request with recipient, payment source, amount, and transaction details.
Validation and orchestration	The request is authenticated and validated, and merchant-level funding and ledger controls are applied.
Execution	The payout is executed against the available funding balance through the applicable push-to-card rail.
Ledger and status	Ledger movements are recorded and a payout notification is returned to the platform with correlating identifiers.
Settlement adjustments	Next-day settlement activity, including rejects, chargebacks, and adjustments, is applied to the relevant balances.
Daily balance sweep	An automated nightly sweep restores a negative payout funding balance from the acquiring settlement account.

Funding Model

Payouts are funded by the platform's own acceptance activity rather than a separate prefunding step.

Card acceptance proceeds are credited to the primary ledger and establish the payout funding balance.
Payouts are debited from the payout funding balance at execution.
Next-day settlement processing identifies rejects, chargebacks, and adjustments and applies them to the appropriate balance.
Where payouts leave the payout funding balance negative, an automated nightly sweep debits the acquiring settlement account to clear the position.
Ledger structure is set up once during implementation and reused for all subsequent activity.

Payout Request Model

Each payout is submitted as a single, self-contained request. The request is processed without checking for, or creating, a party for the recipient.

Payload category	Content
Recipient	Recipient information required for the selected payout rail.
Payment source	Recipient card supplied as an encrypted PaymentCard (target.sourceType = PaymentCard), using encryptionData generated with the MUPK.
Merchant context	Merchant identification and applicable configuration context.
Transaction details	Requested operation, platform transaction reference, and correlation information.
Amount	Payout amount and currency.
Funding context	Information that associates the payout with the available funding balance.
Additional data	Data required for routing, operations, reconciliation, or reporting.

Integration guidance

Send complete and valid data in every request. Because no party is created, each request must stand on its own.
Generate and persist a unique platform transaction reference for every payout to support status tracking and reconciliation.
Encrypt card data client-side with an active MUPK for the selected environment. Never write clear-text PAN, security code, or the unencrypted block to logs, analytics, or source control.
Do not reuse a key across certification and production environments.
Treat payout outcomes as asynchronous. Use the payout notification rather than assuming success at submission.
Monitor your funding balance relative to expected payout volume, particularly around settlement adjustments.

Recipient Handling and Compliance Responsibility

Straight-through processing is configured at the merchant level. When enabled, recipient data flows with the payout request, and no party is created or activated for the recipient before payment.

Under this model, the platform retains responsibility for recipient KYC, KYB, and applicable recipient-level regulatory compliance. Platforms should confirm that their compliance program covers the recipients they pay before enabling this capability.

Supported Payout Rails

Payouts are executed as push-to-card disbursements through Visa Direct and Mastercard Send, as applicable to the recipient's card.

Integration Model

API-Led

Straight-Through Disbursement is delivered through an API-led integration. The platform owns the entire recipient experience and submits payout requests directly through the APIs. No hosted or Fiserv-rendered screens are involved.

This differs from the hosted and embedded models used for Onboard Participant flows, where Fiserv renders or embeds parts of the user-facing experience. Because no party is created for the recipient, there is no recipient-facing flow to render.

Integration Steps

The Straight-Through Disbursement guide in the API documentation walks through eight steps, grouped here by purpose:

Stage	Guide steps
Secure card data	Step 1: Generate unencrypted encryptionBlock; Step 2: Generate encryptionBlockFields; Step 3: Generate key; Step 4: Perform RSA encryption; Step 5: Form encryptionData
Build payment source	Step 6: Build the payment source
Submit payout	Step 7: Submit the payout without onboarding
Receive outcome	Step 8: Receive the payout notification

Status, Exceptions, and Reconciliation

Every payout carries correlating identifiers from request through execution, ledger posting, and settlement, so platforms and operations teams can trace activity end to end.

A payout notification is returned for each payout.
Failed, rejected, returned, cancelled, reversed, or retried payouts are handled as supported by the interface contract.
Settlement adjustments, rejects, and chargebacks are applied to the appropriate balances and remain traceable for reconciliation.
Settlement reporting reflects primary ledger, payout funding balance, and sweep activity.

Specific status codes and payout notification events are configured during implementation.

Common Business Outcomes

Platforms use Straight-Through Disbursement to:

Pay large numbers of consumers without creating a party for each recipient
Fund disbursements directly from card acceptance proceeds
Deliver funds to eligible cards through push-to-card rails
Run money-in and money-out through a single integration
Automatically manage the payout funding balance through a nightly sweep
Trace every payout from request through settlement
Reconcile acceptance, payout, and settlement activity in one reporting view