Authorize.net Now Supports Account Funding Transactions (AFT): What Merchants, ISOs, and ISVs Need to Know
For years, one of the most common frustrations in the payments world has been a simple one: getting money to someone fast. ACH works, but it’s slow. Traditional refunds only work against prior purchases. And adding on a separate payout vendor just to send workers, contractors, or customers their money was time-consuming, costly, and frustrating.
Authorize.net just fixed that. Account Funding Transactions (AFT) are now live on Authorize.net, and for merchants, ISOs, and ISVs operating in any space where payouts matter, this is the infrastructure upgrade you’ve been waiting for.
This post breaks down exactly what AFT is, how it works on Authorize.net, who it’s built for, and what you need to do to implement it correctly.
What Is an Account Funding Transaction (AFT)?
An Account Funding Transaction is a merchant-initiated transaction that pushes funds directly to a cardholder’s Visa or Mastercard account. While standard payments send money from a customer to a merchant, an AFT is just the opposite. The merchant (or platform) initiates the transfer, and the cardholder receives the funds.
This makes AFT purpose-built for any scenario where your business needs to pay out, not collect. Common AFT use cases include:
- Payroll and earnings disbursements: paying workers, contractors, or gig economy participants
- Funds disbursement: platform payouts, marketplace settlements, or earned wage access
- Wallet and prepaid card top-ups: funding digital wallets or reloadable card programs
- Person-to-person (P2P) transfers: enabling users to send money to other users
- Loyalty credit distributions: pushing earned rewards or credits to a cardholder account
- Credit card bill payments: facilitating compliant bill pay transactions
What separates AFT from a standard refund or credit is intent and compliance. An AFT is not tied to a prior purchase. It is a standalone, merchant-initiated money movement with its own set of card network rules, data requirements, and compliance obligations. Authorize.net now supports it natively through the API.
Why This Matters: The Problem AFT Solves
Let’s be direct about the pain point. If your platform pays people — gig workers, nurses on assignment, freelance designers, contractors, marketplace sellers — you’ve likely been living with one of the following compromises:
Option A: ACH transfers. Reliable, cheap, and painfully slow. Two to three business days is the norm. For a worker who completed a job Tuesday night and needs funds Wednesday morning, ACH is not a solution. It’s a frustration.
Option B: A separate payout provider. You add a dedicated disbursement platform to your stack, manage a second integration, pay a second vendor, and introduce a second point of failure. It works, but it’s expensive, complex, and creates reconciliation headaches.
Option C: Non-compliant workarounds. Some platforms have tried processing payouts as standard purchase transactions with incorrect transaction codes. This creates misclassified transactions, triggers issuer fraud flags, and can result in declines, chargebacks, and card network penalties.
AFT on Authorize.net eliminates all three compromises. You process payouts through the same API your team already knows, with the correct transaction classification that card networks require, and workers receive funds on their Visa or Mastercard account in minutes, not days.
How AFT Works on Authorize.net
AFT on Authorize.net is an API-only feature. It is not available through the Virtual Terminal, because the required fields and compliance data cannot be captured through that interface. This is an integration-level capability, which means it lives in your code, which is exactly where it should be for platforms processing payouts at scale.
The Technical Implementation
To submit an AFT, you add an aftInformation object to a standard authCaptureTransaction API request. The core structure looks like this:
{
“createTransactionRequest”: {
“merchantAuthentication”: {
“name”: “YOUR_API_LOGIN_ID”,
“transactionKey”: “YOUR_TRANSACTION_KEY”
},
“transactionRequest”: {
“transactionType”: “authCaptureTransaction”,
“amount”: “150.00”,
“payment”: {
“creditCard”: {
“cardNumber”: “RECIPIENT_CARD_NUMBER”,
“expirationDate”: “2027-12”
}
},
“aftInformation”: {
“aftIndicator”: “true”,
“businessApplicationId”: “FD”,
“recipientInformation”: {
“firstName”: “Jane”,
“lastName”: “Doe”,
“country”: “US”,
“accountId”: “ACCT123456”,
“accountType”: “03”
},
“senderInformation”: {
“firstName”: “Canyon”,
“name”: “Canyon Payments Inc”,
“address”: “123 Main St”,
“city”: “Salt Lake City”,
“state”: “UT”,
“zip”: “84101”,
“country”: “US”,
“type”: “B”
}
}
}
}
}
Three fields do the heavy lifting here.
aftIndicator: true — This explicitly flags the transaction as an Account Funding Transaction. Without it, the request processes as a standard purchase, which is both misclassified and non-compliant for money-movement use cases.
businessApplicationId — This two-character code tells the card network exactly what kind of money movement is happening. It drives network treatment, compliance rules, and routing. Choosing the wrong code can cause declines and put you out of compliance. Here are the codes most relevant to the use cases described in this post:
|
Code |
Use Case |
|---|---|
|
FD |
Funds Disbursement (platform payouts, marketplace settlements) |
|
PD |
Payroll / Pension Disbursement |
|
PP |
Person-to-Person Transfer |
|
WT |
Digital Wallet / Wallet Funding |
|
TU |
Account Top-Up |
|
LO |
Loyalty Credit Distribution |
|
CP |
Credit Card Bill Payment |
Sender and recipient information — This is where most DIY implementations run into trouble. Visa and Mastercard both require structured sender and recipient data for every AFT. This isn’t optional metadata. It’s mandatory for Anti-Money Laundering (AML) compliance, sanctions screening, and issuer decisioning. Missing fields don’t just slow things down; they cause declines and flag your transactions as non-compliant.
Visa vs. Mastercard: What’s Different
Both card networks support AFT, but they have different field requirements. Understanding the distinction before you build saves significant rework.
Visa AFT Requirements
Visa requirements include sender name (first, middle, and last for individuals, or business name for companies), sender state (required for US and Canada transactions), and standard recipient information.
Mastercard AFT Requirements
Mastercard’s requirements are more explicit on the recipient side. You must include the recipient’s first name, last name, country, account ID, and account type. On the sender side, individual senders require first and last name separately; business or government senders use the name field. You cannot mix individual name fields with the business name field. That combination will cause a decline.
The practical approach: populate all reasonable sender and recipient fields for every transaction rather than branching your logic by card type. It’s cleaner code, it satisfies both networks, and it reduces the surface area for compliance failures.
Processor Support: What You Need to Know
AFT availability on Authorize.net depends on your processor. Here’s the current support matrix:
|
Processor |
Supported Card Types |
|---|---|
|
TSYS |
Visa |
|
FDI Global |
Visa and Mastercard |
If your merchants are processing on TSYS, they can run Visa AFTs today. If they’re on FDI Global, they have full Visa and Mastercard AFT support. If they’re on a different processor, contact Authorize.net Support to confirm eligibility before building.
One important detail to note: AFT transactions are processed separately from standard purchase transactions. The setup and enablement process for AFT may differ from your existing merchant account configuration. Merchants must coordinate with their acquirer to confirm processor and network enablement before submitting live AFT transactions. This is not a step you want to skip, since sending live AFTs without proper enablement creates compliance exposure.
The Compliance Layer: Why This Isn’t a DIY Project
AFT is available today, and the Authorize.net documentation is clear and well-structured. But “available” and “simple to implement correctly” are not the same thing.
Here’s what the implementation process actually involves:
- Processor eligibility confirmation. Not every merchant account is automatically enabled for AFT. You need to confirm your processor supports it and that your specific merchant account is eligible.
- Acquirer coordination. Card networks require merchants to be properly registered and enabled for money-movement transactions before going live. This coordination happens between you, your acquirer, and in some cases the card networks directly.
- Correct businessApplicationId selection. This requires understanding your specific use case and verifying the correct code with your acquirer and card networks. Using the wrong code creates compliance failures even if the transaction authorizes.
- Field validation and format compliance. Names must be 35 characters or fewer. Country codes must follow ISO 3166-1 alpha-2 format. State codes must follow USPS 2-letter format. These aren’t suggestions, because incorrect fields cause declines.
- Sandbox testing and end-to-end validation. Before going live, every AFT implementation should be tested in the Authorize.net sandbox with your actual use case scenarios.
If you miss any of these steps, you’re not just risking declines. You’re risking non-compliant processing, which carries card network penalties.
Who Should Be Moving on This Right Now
ISVs Building for High-Velocity Payout Verticals
If you’re building software for any of the following verticals, AFT should be on your product roadmap immediately:
Gig economy and delivery platforms: Your workers completed jobs. They need to be paid. The platforms that offer fast, reliable payouts retain workers. The ones that don’t lose them to competitors who do. AFT turns a 3-day ACH wait into a same-session payout.
Healthcare staffing platforms: Nurses, locum physicians, and allied health workers often take assignments across multiple facilities. Getting paid quickly is usually more than a preference; for many workers, it’s a financial necessity. AFT-powered disbursements are a meaningful differentiator in this vertical.
Construction and trades platforms: Contractors and subcontractors operating on daily or per-job payment terms have real cash flow needs. A platform that pays within minutes of job completion is one they’ll stay with.
Creator and freelance marketplaces: Designers, developers, writers, and content creators working across multiple clients need fast access to their earnings. Platforms that deliver that win loyalty. Platforms that make creators wait lose them to competitors.
Earned wage access (EWA) products: If your HR or payroll platform offers on-demand pay, AFT is the correct infrastructure to deliver it compliantly and at speed.
ISOs Looking to Add Value for Existing Merchants
For ISOs, AFT represents a genuine conversation-starter with merchants who are already processing on Authorize.net. Most of them don’t know this capability exists yet. If you can walk into a conversation with a staffing agency, gig platform, or marketplace and explain how they can add instant payouts to their existing integration without switching processors or adding vendors, you’re solving a real business problem.
That’s a different conversation, and a stickier merchant relationship.
Merchants Operating Money-Movement Use Cases
If your business is actively processing wallet top-ups, P2P transfers, payroll disbursements, or marketplace payouts through a standard purchase transaction type today, you have a compliance exposure. Card networks have been progressively tightening requirements around money-movement transactions, and misclassified transactions are increasingly flagged and penalized.
AFT gives you the compliant path forward, and it lives in the same API you’re already using.
What Canyon Payments Does That Documentation Alone Can’t
The Authorize.net documentation for AFT is thorough and well-written. You can read it, understand the concept, and hand it to your development team. What the documentation doesn’t do is navigate the steps that happen before and around the API work.
At Canyon Payments, here’s what we bring to an AFT implementation:
- Eligibility assessment: We confirm your processor and merchant account configuration before your team writes a line of code, so you’re not building toward a dead end.
- Acquirer coordination: We manage the communication with your acquirer and handle the card network enablement process on your behalf.
- Use case mapping: We identify the correct businessApplicationId for your specific payout scenarios and validate it with the appropriate parties before go-live.
- Implementation guidance: We work alongside your development team to ensure the API integration is structured correctly, fields are validated properly, and the sandbox testing covers your real-world scenarios.
- Ongoing support: After go-live, we’re the team you call when something unexpected happens, not a ticket queue.
We don’t replace your Authorize.net integration. We help it do more.
The Bottom Line
Authorize.net’s support for Account Funding Transactions is a meaningful expansion of what’s possible for merchants, ISOs, and ISVs operating in payment-intensive industries.
The infrastructure to pay people faster (compliantly and through an API your team already uses) is here. The platforms and software companies that move on this now will build a meaningful advantage over those still relying on ACH and workaround approaches.
Fast, compliant payouts aren’t a feature anymore. They’re table stakes for anyone building in the gig economy, staffing, creator, or marketplace space.
If you’re ready to add AFT to your Authorize.net integration, we’d love to talk.
Whether you’re an ISV mapping out your product roadmap, an ISO looking to bring a new capability to your merchant portfolio, or a merchant trying to figure out the right path forward, reach out to the Canyon Payments team. We’ll tell you exactly where you stand and what it takes to get live.
Contact us at canyonpayments.com or send us a direct message. No pressure, no pitch. Just a straight conversation about what’s possible.
Canyon Payments is a payment solutions provider specializing in helping merchants, ISOs, and ISVs implement advanced payment capabilities on Authorize.net and other leading platforms. We combine deep technical knowledge with hands-on implementation support so you can move faster and build better.