Original Credit Transactions: The Rules for Paying Out

Original Credit Transactions are how money gets pushed onto a card instead of pulled off one. Payouts to sellers, gig worker earnings, insurance settlements, refunds that aren't tied to an original sale, winnings. If you've ever sent money to someone's debit card and watched it land in seconds, that was an OCT.

They run on their own rulebook, and it's stricter than most people building payouts expect. Section 8.4 of the Visa Core Rules and Visa Product and Service Rules (18 April 2026) sets out what an originating acquirer, a merchant, and a recipient issuer each have to do.

The short version: you have to tell Visa before you start, you can barely reverse one, and it must never look like a refund on the customer's statement.

An OCT Is Not a Refund, and Can't Look Like One#

This is the rule most people get wrong, and it's explicit.

A recipient issuer must clearly describe the payment on the cardholder statement and must not label the payment as a refund. For an OCT sent to a credit card account, the funds have to post as a payment (ID# 0004064).

That distinction matters commercially. A refund reverses a purchase, so it reduces what the cardholder owes on that specific sale. An OCT is new money arriving. Presenting one as the other confuses reconciliation on the cardholder's side and misrepresents what happened.

If you're used to thinking about refunds and disputes as the only ways money flows back, this is a third path with none of the same mechanics.

You Have to Notify Visa Before You Start#

You can't just switch payouts on because your processor supports them.

An originating acquirer, whether directly or through its merchants or service providers, must validate sender data, comply with applicable anti-money laundering and anti-terrorist financing requirements, and properly disclose to the sender what sender data is being collected. Then comes the line that catches people out: the originating acquirer must notify Visa before it, or its merchant or service provider, starts to process any Original Credit Transactions (ID# 0005328).

So there's a gate before the first payout, and it sits with your acquirer. If you're planning a payouts feature, that conversation happens early, not the week before launch.

One Sender, One Recipient#

Short rule, real consequences. An Original Credit Transaction must involve only a single sender and a single recipient (ID# 0025765).

You can't bundle a payout run into one OCT. A batch of a thousand sellers is a thousand transactions, each with its own sender and recipient. That shapes your fees, your reconciliation, and your error handling, and it's worth knowing before you design the batch job rather than after.

A Payout Is Close to Final#

Here's where OCTs differ most sharply from a card sale.

An originating acquirer, merchant, or service provider must not reverse an Original Credit Transaction that was initiated as an Online Financial Transaction. Where a reversal is permitted at all, it has to be processed within one business day of the processing date, and only for four reasons (ID# 0026074):

• Incorrect payment credential
• Incorrect transaction amount
• Duplicate processing
• Incorrect transaction code

Read that list closely. "We changed our mind," "the seller turned out to be fraudulent," and "the customer charged back the underlying order" are not on it. Once the money is pushed, pulling it back is not a mechanism the network gives you.

The April 2026 edition tightened this further. An acquirer or originating acquirer must not make corrections to an OCT without approval from an issuer or recipient issuer, and both sides now have to use a good faith collaboration through Visa Resolve Online, responding within 5 calendar days of the inquiry, when asking about something like a duplicate or an incorrect amount (ID# 0031161 and ID# 0031162).

The practical consequence is that your controls have to sit before the payout, because there's very little after it. Verify the recipient, verify the amount, and hold anything uncertain, because the release is one way.

How Fast the Money Has to Move#

The speed rules are on the receiving side, and they're tighter than most merchants realise.

Recipient issuers also must not apply additional funds transfer fees for consumer cards (ID# 0004064). If your payout recipients are consumers, they shouldn't be losing a slice to their own bank on arrival.

That 60 second US figure is what makes "instant payout to your debit card" a real product rather than marketing. It's a rule, not a best effort.

Not Every Card Can Receive One#

A member must accept an incoming OCT unless prohibited by applicable law, and if it is prohibited, the member has to submit a written request to Visa to block them (ID# 0004062).

The exclusions are the useful part. That acceptance requirement doesn't cover non-reloadable prepaid cards, reloadable prepaid cards where cardholder data isn't on file, or card products where the source of loads may be restricted, which the rules illustrate with government, healthcare, insurance, meal voucher, payroll and youth products. It also does not apply to Visa Commercial Cards.

So a payout to a business card is not something you can count on landing. If you're paying suppliers or contractors who give you a corporate card, expect failures and design for a fallback. Checking the account first with Account Name Inquiry is optional under the rules, but this is exactly the situation it exists for.

When the Money Doesn't Land#

There's a defined path, and it runs on a clock.

To get confirmation that funds actually posted, the originating acquirer submits an inquiry through Visa Resolve Online, and the recipient issuer must respond within 5 calendar days (ID# 0027329). If the recipient issuer fails to confirm posting within those 5 days, the originating acquirer may submit a transaction adjustment, which has to be submitted within 30 calendar days of the processing date of the original OCT (ID# 0027330).

From the other direction, an issuer can dispute under condition 13.8, Original Credit Transaction Not Accepted, for one of two reasons only: the recipient refused it, or OCTs are prohibited by applicable law. The time limit is 120 calendar days from the OCT processing date, and the dispute is invalid for a mobile push payment transaction (ID# 0030355, ID# 0030553, ID# 0030357).

Note what isn't there. There's no dispute condition for "the payout shouldn't have been sent."

If You're Building Payouts#

Four things follow from all of the above.

Start the acquirer conversation early, because Visa has to be notified before your first OCT and that isn't a same-week task.

Put your fraud and verification controls in front of the payout, not behind it. The reversal window is one business day and four narrow reasons, so anything you'd want to undo has to be caught before it goes.

Budget per-transaction, not per-batch. One sender, one recipient, every time.

Get your statement descriptor right. The payment must not read as a refund, and this is the kind of detail that generates support tickets and confused reconciliation for years if you set it wrong at launch. The same care applies to your billing descriptors on the pull side.