Overview

An Account Funding Transaction (AFT) is a merchant-initiated transaction that pushes funds directly to a cardholder's account, reversing the standard payment direction from cardholder to merchant. AFTs are used for payouts, refunds, payroll disbursements, account top-ups, loyalty credits, and person-to-person (P2P) transfers.

On Authorize.net, AFTs are implemented by adding an aftInformation object to a standard authCaptureTransaction API request. Unlike standard sale transactions, AFTs are regulated money-movement transactions with strict field requirements enforced by Visa and Mastercard. Missing or malformed fields can result in declines or non-compliant processing.

AFTs require a valid businessApplicationId to categorize the transaction type, as well as accurate recipient and sender information. These fields drive network validation, routing, and compliance — not interchange optimization.

Merchants must coordinate with their acquirer to confirm processor and network enablement before sending live AFT transactions.

Benefits and Use Cases

AFTs enable the following merchant-initiated fund movement scenarios:

• Payouts and disbursements to cardholders
• Payroll and pension payments
• Account top-ups and wallet funding
• Loyalty credit distributions
• Person-to-person (P2P) transfers
• Credit card bill payments

Processor Support and Enablement

AFT support on Authorize.net depends on processor implementation and Authorize.net enablement. The table below lists currently supported processors and their supported card types.

Processor support may vary by card brand and transaction type. If your processor is not listed, contact Authorize.net Support to confirm eligibility.

Implementing AFTs via the Authorize.net API

AFTs are supported through API integrations only. To send an AFT, add the aftInformation object to the transactionRequest body of a standard authCaptureTransaction request.

Core Required Fields

• aftIndicator — Set to "true" to trigger AFT processing
• businessApplicationId — Required 2-character code that identifies the transaction category

Recipient and Sender Information

Provide both recipientInformation and senderInformation objects in accordance with network requirements. Mastercard generally requires more recipient fields than Visa.

• Recipient fields: firstName, lastName, accountId, accountType, country
• Sender fields (individual): firstName, lastName (do not combine with the business name field)
• Sender fields (business): name (do not combine with individual firstName/lastName fields)
• Additional sender fields: address, city, state, zip, country, type (use B for business or I for individual)

Account Type Codes

Business Application IDs

The businessApplicationId field categorizes the AFT for network treatment and compliance. This value does not affect interchange. Verify supported codes with your acquirer and card networks before implementation.

Mastercard-Specific AFT Requirements

When processing AFTs on Mastercard, the following fields are mandatory. Omitting or mixing these fields can cause declines or non-compliant processing.

Required Recipient Fields (Mastercard)

• recipientInformation.firstName
• recipientInformation.lastName
• recipientInformation.country
• recipientInformation.accountId
• recipientInformation.accountType

Required Sender Fields (Mastercard)

• For an individual sender: senderInformation.firstName + senderInformation.lastName
• For a business or government sender: senderInformation.name
• senderInformation.state
• senderInformation.type — Use B for business or I for individual

Important: Do not mix senderInformation.name with individual sender name fields (firstName / lastName). These fields drive network validation and routing. Omitting or mixing fields can cause declines or non-compliant processing.

Coordinate with your acquirer for processor-specific requirements and testing before submitting live Mastercard AFT transactions.

Example API Request (JSON)

The following example demonstrates a person-to-person (P2P) AFT request using an individual sender and recipient on the Authorize.net API:

{
  "createTransactionRequest": {
    "merchantAuthentication": {
      "name": "YOUR_API_LOGIN_ID",
      "transactionKey": "YOUR_TRANSACTION_KEY"
    },
    "transactionRequest": {
      "transactionType": "authCaptureTransaction",
      "amount": "100.00",
      "payment": {
        "creditCard": {
          "cardNumber": "5424000000000015",
          "expirationDate": "2025-12"
        }
      },
      "aftInformation": {
        "aftIndicator": "true",
        "businessApplicationId": "PP",
        "recipientInformation": {
          "firstName": "Jane",
          "lastName": "Doe",
          "country": "US",
          "accountId": "ACCT123456",
          "accountType": "03"
        },
        "senderInformation": {
          "firstName": "John",
          "lastName": "Smith",
          "address": "123 Main St",
          "city": "Seattle",
          "state": "WA",
          "zip": "98101",
          "country": "US",
          "type": "I"
        }
      }
    }
  }
}
  

Best Practices

• Populate all reasonable recipient and sender fields to satisfy both Visa and Mastercard requirements, rather than branching by Bank Identification Number (BIN) lookup
• Validate field formats and lengths before submission — names must be 35 characters or fewer, country codes must follow ISO 3166-1 alpha-2 format, and state codes must follow United States Postal Service (USPS) 2-letter format
• Use individual name fields (firstName / lastName) for individual senders and the name field for business senders — do not combine both
• Store request and response pairs for audit, reconciliation, and dispute handling
• Test end-to-end in the sandbox environment and coordinate with your acquirer for processor and network enablement before going live
• Verify supported businessApplicationId codes with your acquirer and card networks before implementation

Troubleshooting and Common Scenarios

Response Handling

• Success: transactionResponse.responseCode == "1" — Store the authCode and transId values for your records
• Decline or Error: responseCode != "1" — Inspect transactionResponse.errors for details and apply the appropriate fix from the table below

Common AFT Validation Errors and Resolutions

Frequently Asked Questions

What AFTs Are and How They Work

• What is an Account Funding Transaction (AFT), and how is it different from a standard refund?
  • An AFT is a merchant-initiated movement of funds that is not tied to a prior purchase. A standard refund reverses a previous charge back to the original card, while an AFT moves funds for use cases such as wallet top-ups, prepaid card loads, payroll, payouts, or peer-to-peer (P2P) transfers.
  • AFTs are money-movement transactions, not purchases of goods or services. They require additional sender and recipient data that standard refunds do not.
• Who should use AFT?
  • AFT is designed for merchants that support account funding experiences, including:
    • Wallet top-ups
    • Prepaid card loads
    • Payroll or trading account funding
    • Peer-to-peer (P2P) transfers
• Who should not use AFT?
  • AFT must not be used for:
    • Purchasing goods or services
    • Retail or subscription payments
    • Funding a merchant's own settlement or operating account
  • For these use cases, standard purchase transactions should continue to be used.
• Is AFT mandatory for all merchants?
  • No. AFT is use-case based, not merchant-wide. Only merchants that support account funding scenarios need to adopt AFT. Merchants that only process purchase transactions do not need to make changes.

Processor and Setup Requirements

• Does my processor support AFTs?
  • Currently, TSYS supports Visa AFTs, and FDiGlobal supports both Visa and Mastercard AFTs.
  • If your processor is not listed, contact Authorize.net Support to confirm eligibility before implementing.
• Do I need new processor credentials?
  • AFT transactions are processed separately from purchase transactions. Merchants onboarding for AFT are set up according to processor and card-network requirements, which may differ from purchase transaction configurations.
• Is AFT a breaking change to my existing integration?
  • No. AFT is opt-in and requires separate setup. Existing purchase transaction integrations are not affected.
• Is AFT available through the Authorize.net Virtual Terminal?
  • No. Transactions processed through the Authorize.net Virtual Terminal are not compliant with AFT requirements because the required AFT indicators and sender/recipient data fields are not supported in that interface.
• Is AFT available through the Authorize.net API?
  • Yes. AFT is supported via API-based integrations only. Merchants must submit AFT transactions using the Authorize.net API with the required AFT-specific fields.

Required Data Fields

• What information is required for AFT transactions?
  • AFT transactions require additional data so issuers can clearly understand the intent and flow of funds. You must provide:
    • aftIndicator — explicitly flags the transaction as an AFT
    • businessApplicationId — identifies the funding use case
    • Bill To information — identifies the card being charged
    • Recipient information — identifies who receives the funds
    • Sender information — identifies who is funding the transaction
  • Transactions missing required AFT fields may be declined or processed as purchase transactions, which is noncompliant for AFT use cases.
• Why is sender information required in addition to Bill To information?
  • While Bill To identifies the card being charged and Recipient information identifies where funds are going, sender information is required to clearly identify who is funding the transaction.
  • Sender information supports Anti-Money Laundering (AML) controls, sanctions screening, and issuer decisioning. Without it, transactions may be rejected or processed as noncompliant purchases.
• Which businessApplicationId should I use?
  • Select the code that most accurately describes the purpose of the transaction — such as P2P transfers, payroll, or general funds disbursement.
  • This value drives network treatment and compliance rules. Verify the correct value with your acquirer and card networks before going live.
• Is the businessApplicationId used for interchange optimization?
  • No. The businessApplicationId is used for network treatment and compliance categorization only. It does not affect interchange rates.

Additional Resources

• Authorize.net API Reference — Full API documentation for card payment integrations, including field definitions and request/response schemas

Glossary

• AFT — Account Funding Transaction: A merchant-initiated transaction that pushes funds to a cardholder account, reversing the standard payment direction
• API — Application Programming Interface: A set of protocols that allows software systems to communicate with each other; used here to submit AFT requests to Authorize.net
• BIN — Bank Identification Number: The first six digits of a payment card number that identify the issuing institution
• ISO — International Organization for Standardization: The body that publishes internationally recognized standards, including ISO 3166-1 alpha-2 country codes used in AFT fields
• JSON — JavaScript Object Notation: A lightweight data format used to structure API request and response payloads
• P2P — Person-to-Person: A transfer of funds between two individuals; one of the common AFT use cases
• RTN — Routing Transit Number: A nine-digit code that identifies a US financial institution; used with account type code 01
• USPS — United States Postal Service: The US postal authority whose 2-letter state abbreviation codes are required for state fields in AFT requests
• USPS — United States Postal Service: The US postal authority whose 2-letter state abbreviation codes are required for state fields in AFT requests
• 2-char / 2-character code — Two-Character Code: A standardized short code used to identify transaction categories in the businessApplicationId field