A US Visa issuer has 60 seconds to make a domestic Fast Funds payout spendable. Everywhere else the Fast Funds clock is 30 minutes, and for a UK credit card Fast Funds is not mandatory at all: the issuer only has to post the money by the end of the business day. If your product says "instant payout", the card's country and type decide whether that is true.
Account Funding Transactions (AFTs) pull money off a card to fund something. Original Credit Transactions (OCTs) push money onto a card. The pages ranking for them are glossaries that define the terms and stop; none gives the codes, scheme rules or API fields a payout flow needs. Scheme rules here are from the Visa Rules edition of 18 April 2026, and PSP fields were checked against official docs and OpenAPI specs on 25 October 2026.
What Is an Account Funding Transaction (AFT)?
An AFT pulls funds from a Visa card to load another account: a wallet, a prepaid card, a brokerage account, or the first leg of a person-to-person transfer. It looks like a purchase to the cardholder, but it is not one. Visa's rules (section 7.4.1.1) say an AFT must not be a payment for goods or services or the funding of a merchant account.
Visa makes AFT coding compulsory for a specific list:
- reloading prepaid cards
- card-absent funding of P2P and account-to-account transfers
- funding disbursements from Visa corporate and business debit cards, such as payroll
- funding stored value and staged digital wallets, unless it is back-to-back funding
- buying liquid and cryptocurrency assets
Every AFT must carry the AFT indicator and the correct business application identifier (BAI) in both the authorisation and the clearing record. Debt repayment was split by region from 25 July 2026: it must be an AFT in Asia Pacific, CEMEA and most of Latin America, and must not be one in Canada, Europe, the US, Chile and Puerto Rico. A UK lender taking card repayments should not flag them as AFTs.
What Is an Original Credit Transaction (OCT)?
An OCT pushes money onto a card. Visa defines it as a credit that "does not require a prior purchase", except when it is used as a Faster Refund. That is the key difference from a refund, which has to reference an original sale. Payroll, marketplace seller payouts, insurance claims and gambling winnings all travel as OCTs.
The recipient issuer's obligations (section 8.4.2.2) are tighter than most payout docs suggest:
- post the OCT within 2 business days, or the same business day for an intra-Europe transaction
- under Fast Funds, make the money available within 30 minutes of approval, or 60 seconds for a US domestic OCT
- post an OCT to a credit card as a payment, and not label it on the statement as a refund
- charge no extra funds-transfer fee on consumer cards
AFT vs OCT: The Differences That Matter in Code
| AFT | OCT | |
|---|---|---|
| Direction | Pull from the card | Push to the card |
| Processing code (DE 3) | 10 (Visa AFT) | 26 (Visa), 28 (Mastercard payment transaction) |
| Visa Direct endpoint | POST /visadirect/fundstransfer/v1/pullfundstransactions | POST /visadirect/fundstransfer/v1/pushfundstransactions |
| Mastercard Send endpoint | POST /v1/partners/{partnerId}/transfers/funding | POST /v1/partners/{partnerId}/transfers/payment |
| Mastercard naming | Funding transaction | Payment transaction |
| 3DS | Supported (cavv on the pull request, EMV 3DS transType 10) | Not applicable |
| Undo | Visa AFT reversal endpoint; Mastercard funding reversal within 30 minutes if the payment leg fails | One business day, four reasons, never for online OCTs |
| Disputes | Mastercard says funding transactions "have full chargeback rights" | Visa condition 13.8, OCT not accepted, 120 days |
Two Visa Direct field rules catch people when they chain the two legs. The retrievalReferenceNumber (format ydddhhnnnnnn) "must differ between the two methods", but an AFT reversal must reuse the AFT's value. And the OCT's transactionIdentifier must carry the VisaNet transaction ID returned in the AFT response.
The worse trap is a field name. In the pull (AFT) API, senderAccountNumber is mandatory for cross-border AFTs and holds the destination account being funded: an IBAN, a wallet number or a prepaid PAN. In the push (OCT) API, the same field name holds the sender's card number. Share one serialiser across both calls and one of them will be wrong.
There is no refund path for a Visa AFT either. Mastercard's gateway docs say "Visa AFT does not support refunds. Use VOID instead." Visa corrects AFT errors by reversal or credit adjustment. A settled top-up the customer wants back is a withdrawal, and to a card it travels as an OCT, coded and data-checked like any other payout.
Visa BAI vs Mastercard TTI Codes
Visa calls the purpose code a BAI and carries it in Field 104 Usage 2, dataset 57, tag 01. Mastercard calls it a transaction type identifier (TTI) and carries it in DE 48 subelement 77. The same business flow has a different code on each scheme, and Mastercard adds F-prefixed codes for the funding leg alongside the C-prefixed payment codes.
| Use case | Visa BAI | Mastercard funding TTI | Mastercard payment TTI |
|---|---|---|---|
| Person to person | PP | F07 | C07 |
| Transfer to own account | AA | F52 | C52 |
| Pay own credit card bill | CP | F54 | C54 |
| Prepaid load or top-up | TU | F64 | n/a |
| Staged digital wallet | WT | F61 | n/a |
| Business disbursement | FD | F55 | C55 |
| Business to business | BB | F65 | C65 |
| Government disbursement | GD | n/a | C56 |
| Rapid merchant settlement | MD | n/a | C57 |
| Gambling payout | OG (online), GP (other) | n/a | C04 |
| Fast refund | MI | n/a | C60 |
Visa's own guidance adds conditions. AA "applies to transactions where the sender and recipient are the same person". PP is for AFTs only "when both AFTs and OCTs are supported"; otherwise the funding leg uses FT. The BAIs valid on an AFT, per Visa's acceptance documentation, are AA, BI, FD, FT, PD, PP, TU and WT, with BI limited to the US.
The MCC has to agree with the BAI. Visa's wallet table says staged wallet funding uses MCC 6051 with BAI WT, while stored value wallet funding uses 4829, 6012 or 6540 with BAI FT. Mastercard's gateway lists 4829, 6051, 6211, 6540 and 6538 as the MCCs eligible for funding transactions. A wallet top-up coded under a retail MCC such as 5999 matches neither list.
How Fast Are Push-to-Card Payouts? Visa Fast Funds by Region
Fast Funds is Visa's commitment that money pushed by OCT is usable within 30 minutes. Whether an issuer must offer it depends on region and card type (Table 8-1):
| Region | Fast Funds mandatory for |
|---|---|
| US, Asia Pacific | Any issuer that accepts OCTs online |
| Europe, including the UK | Online-capable issuers of debit, deferred debit and fully KYC'd reloadable prepaid cards; Romania adds credit cards |
| Canada | Debit, reloadable prepaid and Plus cards |
| Latin America | Debit and prepaid cards |
| CEMEA | Countries and products listed in Visa's processing guide |
Outside Fast Funds the posting clock applies: same business day within Europe, 2 business days elsewhere. A UK seller with a UK credit card is only guaranteed the money today, not in 30 minutes. If a US platform pays that same card, the wait can stretch to 2 business days.
Mastercard's program standards sit behind a login, so I won't quote a Mastercard deadline. The PSPs report fast funds per card, not per scheme, and that is the signal to build on.
How to Check If a Card Can Receive a Payout
Every serious payout API has an eligibility check, and each has a different shape.
| Check | Call | What comes back |
|---|---|---|
| Visa Funds Transfer Attributes Inquiry | POST /paai/fundstransferattinq/v5/cardattributes/fundstransferinquiry | Push, fast funds, gambling and pull flags, domestic and cross-border; v2 fastFundsIndicator B, D or N |
| Mastercard Send Account Information | PUT /send/v1/partners/{partnerId}/accounts/account-info | sending_eligibility.eligible (funding), receiving_eligibility.eligible (payment) |
| Adyen | Zero-amount /payments with "Card bin payout details" enabled | payoutEligible Y, D (Mastercard domestic only), N, U; fundsAvailability I or N |
| Checkout.com | POST /metadata/card with format: "card_payouts" | Six keys, each fast_funds, standard, not_supported or unknown |
| Stripe Connect | GET /v1/accounts/{id}/external_accounts | available_payout_methods contains instant |
| TabaPay | Query Card | card.push.enabled, availability Immediate, Next Business Day or Few Business Days |
Checkout.com's response shows best how this really works. Its six keys split domestic from cross-border, and money transfer from non-money transfer and gambling. One card can be fast_funds for a payroll payout and not_supported for gambling winnings. A single "can receive payouts" boolean in your schema throws that away.
AFT and OCT Fields in Stripe, Adyen and Checkout.com
Stripe does OCT-style payouts through Connect Instant Payouts:POST /v1/payouts with method=instant and a destination, on the connected account. Stripe charges platforms "a 1% fee for all Instant Payouts", with a range of £0.40 to £9,999 per payout in GB and €0.40 to €9,999 in the euro area. In the UK the destination can be a debit card or a bank account; US prepaid cards are excluded. Stripe's public API has no AFT flag. One exists only in the private-preview OpenAPI spec, as payment_details[money_services][transaction_type] with values account_funding and debt_repayment, plus sender_details and beneficiary_details objects, which you cannot ship on yet.
Adyen sends card payouts through the Transfers API: POST /btl/v4/transfers with category: "card", a counterparty.card.cardHolder and a counterparty.card.cardIdentification (PAN or storedPaymentMethodId). The classic Payout API v68 is deprecated and closed to new integrations. AFTs are called "instant card funding" and use fundOrigin and fundRecipient on /payments, once Adyen has your compliance documents and support has switched it on. A wallet top-up requires fundOrigin.shopperEmail, fundOrigin.telephoneNumber and fundRecipient.walletIdentifier. Names must be ASCII, at least 3 characters for first plus last name, and not a placeholder like "John Doe". Neither the Checkout v72 nor the Transfers v4 spec has a BAI field, so the scheme code is set on Adyen's side, not in your request.
Checkout.com is the most explicit. A card payout is POST /payments with source.type: "currency_account", a destination, and a mandatory instruction.funds_transfer_type that takes the raw scheme codes (AA, FD, PP, OG for Visa; C07, C55, C04 for Mastercard). If the payout follows an earlier AFT, previous_payment_id links them, and it accepts the scheme transaction ID when another PSP processed the AFT. An AFT is a normal payment with processing.aft: true plus sender and recipient objects. Banned name values such as TEST, VISA and NA return a 422, and senders or recipients in countries such as Russia, Iran or North Korea are declined.
| Stripe | Adyen | Checkout.com | |
|---|---|---|---|
| Push to card | Instant Payouts, method=instant | Transfers v4, category: "card" | /payments with destination |
| AFT flag | Private preview only | fundOrigin / fundRecipient | processing.aft: true |
| Purpose code exposed | No | No | Yes, funds_transfer_type |
| Link AFT to OCT | n/a | Not documented | previous_payment_id |
| Eligibility | available_payout_methods | payoutEligible | card_payouts metadata |
The trade-off is control against effort. Stripe hides the scheme entirely, which is fine for paying sellers and useless for a remittance or wallet product that needs its own BAI. Checkout.com hands you the raw codes and the duty to get them right.
Push-to-Card vs Faster Payments for UK Payouts
This is my position, and I'd defend it in a design review: for a UK platform paying UK residents, Faster Payments should be the default rail and push-to-card the fallback.
The numbers favour the bank rail. Faster Payments has a £1m scheme limit against Stripe's £9,999 card payout ceiling. It reaches almost every UK current account, and Confirmation of Payee lets you check the account name before you send. Fast Funds in the UK is only mandatory for debit and prepaid cards, so "instant to card" is not guaranteed for every UK card. The bank-side trade-offs are in the Faster Payments vs Bacs vs CHAPS guide.
Push-to-card wins in three cases:
- Gambling. When a gambling merchant pays winnings to a Visa cardholder, rule 5.8.18.3 allows only an OCT, and in Europe it must go "to the same Payment Credential that was used to place the winning wager". If the player deposited by Visa card, that card is where the winnings go.
- You only hold a card. A gig platform that onboarded workers with a debit card can pay them without collecting bank details.
- Cross-border into the EEA. Adyen supports domestic GBP card payouts from the UK and cross-border payouts to EEA cards, which is simpler than running SEPA for a few hundred recipients.
AFT Disputes, 3DS and SCA in the UK and EEA
An AFT is a card-not-present debit started by the cardholder. EMV 3DS has a dedicated transaction type for it (transType 10, "Account Funding"), and the Visa Direct pull request carries a cavv. I found no regulator or scheme text that treats AFTs specially under UK or EU SCA rules, so the normal customer-initiated rules apply, exemptions included; the SCA exemptions guide covers which.
Liability is where AFTs differ. Mastercard says funding transactions keep "full chargeback rights", so a stolen card used to top up a wallet comes back as a fraud dispute after the money has left. In the US, 3DS will not protect you: Visa's dispute condition 10.4 applies "regardless of the Electronic Commerce Indicator value" for domestic e-commerce on MCCs 4829, 5967, 6051, 6540, 7801, 7802 and 7995. Three of the main AFT MCCs are on that list.
The UK adds a data rule for lenders and banks. A card-absent transaction under MCC 6012 in the UK must carry the recipient's date of birth, a partly masked account number, a partial postcode and last name, which the issuer checks against its own records. If you take card repayments online in the UK, collect those four fields at checkout.
What This Means for Payout Engineering Teams
- Model a transfer as two linked records, the AFT and the OCT, and store the scheme transaction ID from the first to send on the second (
transactionIdentifieron Visa Direct,previous_payment_idon Checkout.com). - Own your purpose enum. Keep values like
p2p,own_account,wallet_topupandgambling_payoutinternally and map them to BAI, TTI or FTT at the PSP edge. Never let a Visa code leak into a Mastercard request. - Check eligibility per card, per use case, per corridor, when the card is added and again before its first payout. Store the four-way result, not a boolean.
- Promise "today", not "instant", for UK credit cards. Show "within 30 minutes" only when the eligibility check returned fast funds.
- Validate sender and recipient data before calling the PSP: ASCII names of at least 3 characters, no placeholders, 30 characters maximum for Visa's
recipientName, and date of birth for cross-border Visa AFTs. - Treat OCTs as final. Put a hold-and-review step before sending, because you get one business day and four reasons to reverse.
- Price in the dispute tail. Instant payouts reach sellers before card disputes arrive; the Stripe Connect vs Adyen liability breakdown covers who absorbs the loss.