Funding transactions with Visa and Mastercard

Learn how to integrate Visa and Mastercard funding transactions with the emerchantpay Payment Gateway API.

Introduction

Funding transactions are card transactions that move money into another account, card, bank account, or digital wallet. Common use cases include account top-ups, wallet loads, remittances, prepaid card loads, account-to-account transfers, and selected liquid asset, securities, crypto, or gift card flows, depending on the scheme rules and transaction setup.

Visa and Mastercard support these transactions under different names:

Visa: Account Funding Transactions (AFTs), as part of Visa Direct.
Mastercard: Funding Transactions, supported through MoneySend / Mastercard Send.

The emerchantpay integration is similar for both schemes. You must classify the funding use case correctly and provide the applicable funding, sender and receiver details in your API request.

Note: Some funding-like transactions may instead be treated as purchases or quasi-cash transactions. Quasi-cash generally refers to transactions involving cash-like items or cash substitutes that can be easily converted to cash. Whether a transaction should be treated as funding, purchase or quasi-cash depends on the scheme, MCC, region and transaction flow.

Prerequisites

Before sending funding transactions, confirm:

Your transaction flow is eligible to be processed as a funding transaction
Your MCC and business activity are eligible
Your acquirer setup supports the required scheme programme
Your emerchantpay account is configured for your specific use of funding transactions
Any required Visa or Mastercard registration, approval or onboarding is complete

Scheme requirements

Use the table below to understand whether your business activity and MCC (Merchant Category Code) are typically treated as in scope for funding transactions with Visa, Mastercard, or both. Requirements can differ by scheme, region, transaction flow and effective date.

BUSINESS	MCC	VISA	MASTERCARD
Money remittance	4829 – Wire transfer money orders	Use AFTs for money transfer use cases. Set `business_application_identifier` to `person_to_person` or `account_to_account`, depending on whether the funds are sent to another person or to an account held by the same customer.	Mastercard Funding Transactions are mandatory for MCC 4829. Set `identifier_type` to `own_account` or `general_person_to_person`.
Funding digital wallets	6012 – Financial institutions: merchandise, services and debt repayment	Use AFTs when the transaction funds a digital wallet. Set `business_application_identifier` to `wallet_transfer`.	Mastercard does not generally mandate Funding Transactions for MCC 6012 unless the wallet funding relates to cryptocurrency activity.
Crypto and NFTs	6051 – Non-financial institutions: foreign currency, non-fiat currency, money orders, travellers cheques and debt repayment	Use AFTs for eligible transactions involving the direct acquisition of liquid assets, including cryptocurrencies, or the funding of an account or wallet used to purchase such assets. Set `business_application_identifier` to `liquid_assets`. This requirement applies to eligible Visa funding flows and must not be confused with Mastercard’s treatment of direct cryptocurrency purchases, which may continue to use standard purchase coding. Eligibility depends on the underlying transaction, the applicable scheme rules and your approved Visa Direct programme.	Mastercard Funding Transactions are mandatory when the customer is loading a `merchant account` or wallet before buying crypto. Set `identifier_type` to `own_account`. If the transaction is a direct crypto purchase, you may continue using purchase coding.
Securities	6211 – Securities: brokers/dealers	Use AFTs for acquiring liquid assets, including securities, crypto, CFDs, binary options and other eligible high-risk investment products. Set business_application_identifier to `liquid_assets` (except for domestic US transactions, which use `fund_transfer`). High-risk investment transactions require Visa Integrity Risk Program (VIRP) approval and an approved Visa Direct programme. Contact your emerchantpay Account Manager for eligibility and regional requirements.	Mastercard requires Funding Transactions from 01 January 2026 when funds are transferred into another eligible financial account to buy high-risk or other securities. Set `identifier_type` to `own_account`.
Prepaid cards and gift cards	6540 – Non-financial institutions: stored value card purchase/load	Prepaid cards, including gift cards, are outside the Visa AFT mandate. You may use AFTs for eligible transactions where supported by your programme. For prepaid card loads, `prepaid_card_load` is the supported `business_application_identifier`. For other eligible funding flows, `account_to_account` or `person_to_person` may apply, depending on the transaction flow. Purchasing a gift card is not necessarily equivalent to loading a prepaid card. Confirm the applicable identifier and MCC with your emerchantpay Account Manager before processing.	For merchants whose primary activity is selling gift cards online, Mastercard supports two coding options: A Funding Transaction under MCC 6540, using `identifier_type` set to `own_account` or `general_person_to_person`, depending on the transaction flow. A purchase (quasi-cash) transaction under MCC 6051, as permitted by Mastercard’s September 2025 update. Confirm that the selected option is supported for your account, transaction flow, geography and acquirer setup before processing.
Gambling	7995 – Gambling	Not in scope for Visa AFTs, as Visa treats this as quasi-cash.	In Europe, Funding Transactions into gaming or gambling accounts are optionally supported from 01 January 2026. If used, set `identifier_type` to `own_account`.

Note: The table is a non-exhaustive scheme-level guide only. Your final setup depends on your MCC, region, transaction flow, and whether the transaction funds an account before a later purchase or represents a direct purchase. Some use cases may also require registration with the scheme before you submit funding transactions.

If you are unsure whether your transactions are direct purchases, account funding or quasi-cash, contact your emerchantpay Account Manager before you start sending funding transactions.

Mastercard MoneySend Funding Transactions (MCC 6538)

MCC 6538 is specific to Mastercard MoneySend Funding Transactions and does not apply to Visa AFTs. Its use is subject to Mastercard-specific transaction type and geographical restrictions. Availability depends on the applicable Transaction Type Identifier (TTI), transaction geography and your acquirer setup.

Consult the latest Mastercard Transaction Processing Rules and confirm eligibility with your emerchantpay Account Manager before processing Funding Transactions under this MCC.

Request parameters

After confirming that your use case is in scope, include the funding object in your request. Funding transactions are supported by the following Processing API transaction types: authorize, sale, authorize3d, sale3d, recurring_sale, apple_pay and google_pay. The funding object is also supported in WPF Create requests.

The required parameters depend on the card scheme. For Mastercard Funding Transactions, provide identifier_type. For Visa AFTs, provide business_application_identifier.

If the card scheme is not known when you create the request, such as when using the Web Payment Form (WPF), you can include both business_application_identifier and identifier_type. When the card scheme is known, provide the corresponding scheme-specific identifier. Include the applicable sender and receiver details, and provide purpose_of_payment outside the funding object when required for Visa AFTs.

Include the funding object in every funding transaction request within a recurring or merchant-initiated transaction (MIT) series. This applies to initial transactions, subsequent referenced and non-referenced recurring transactions, and merchant-unscheduled transactions. You must provide the applicable funding details with each individual request, not only with the initial transaction.

PARAMETER	REQUIRED	FORMAT	DESCRIPTION
`business_application_identifier`	Visa only	String	Identifies the Visa AFT use case. See the supported Visa business application identifier types.
`identifier_type`	Mastercard only	String	Identifies the Mastercard funding use case. See the supported identifier types.
`sender`	Conditional	Object	Contains the sender’s name, type, reference number and applicable address information. For Mastercard Funding Transactions, sender details are generally optional, but additional requirements apply when the sender is a legal entity. See Sender details and Sender types.
`receiver`	Required	Object	Contains the receiver’s name, country, account details, account type and applicable address information. The receiver’s country (ISO 3166-1 alpha-2) and `account_number` are required for both Visa and Mastercard funding transactions. The `account_number_type` parameter is required for Mastercard only. See Receiver details and receiver account types.
`purpose_of_payment`	Conditional – Visa only	String	Specifies the purpose of a Visa AFT. Required for cards issued in certain countries. Important: This parameter belongs directly inside `payment_transaction`, outside the `funding` object.

Note: Do not choose business_application_identifier, identifier_type and MCC independently. These values must describe the same transaction flow. If the values do not align, the transaction may be rejected or processed incorrectly.

Visa business application identifiers

For Visa Account Funding Transactions (AFTs), use business_application_identifier to identify the funding use case. Select the value that corresponds to the purpose of the transaction.

VALUE	USE WHEN
`funds_disbursement`	Use when funds are disbursed to a recipient.
`pension_disbursement`	Use when retirement or pension-related funds are disbursed to a recipient.
`account_to_account`	Use when your customer funds another eligible account.
`bank_initiated`	Use when a bank initiates the funding transaction for its customer.
`fund_transfer`	Use when funds are transferred for a general funding use case.
`person_to_person`	Use when your customer funds a transfer to another person.
`prepaid_card_load`	Use when your customer funds a prepaid card.
`wallet_transfer`	Use when your customer funds a digital wallet or transfers funds from a digital wallet.
`liquid_assets`	Use when your customer funds liquid asset activity, such as supported crypto or securities flows.

Visa AFTs are also subject to MCC eligibility requirements, which vary depending on the business activity and transaction flow. See the Scheme requirements section for more information.

Mastercard identifier types

For Mastercard Funding Transactions, use identifier_type to identify the funding transaction scenario.

The Required MCCs column lists the Merchant Category Codes (MCCs) associated with each identifier_type. These MCC-to-identifier mappings are validated for Mastercard transactions only.

VALUE	USE WHEN	REQUIRED MCCS
`general_person_to_person`	Use when your customer funds a transfer to another person.	4829, 6538, 6540
`person_to_person_card_account`	Use when your customer funds a transfer to another person’s card account.	4829
`own_account`	Use when your customer funds another eligible account held by the same customer.	4829, 6051, 6211, 6538, 6540, 7800, 7801, 7802, 7994, 7995, 9406
`own_credit_card_bill`	Use when your customer funds payment of their own credit card bill.	4829, 6538
`business_disbursement`	Use when your business sends funds to a recipient.	Any
`government_or_non_profit_disbursement`	Use when a government or non-profit organisation sends funds to a recipient.	Any
`rapid_merchant_settlement`	Use when funds are transferred for merchant settlement.	Any
`general_business_to_business`	Use when one business sends funds to another business.	Any
`own_staged_digital_wallet_account`	Use when your customer funds their own staged digital wallet.	Any
`own_debit_or_prepaid_card_account`	Use when your customer funds their own debit or prepaid card account.	Any

Sender details

The funding.sender object contains information about the person or organisation initiating the funding transaction. Supported fields include name, type, reference_number, country, address, state and city.

For Visa AFTs, name and reference_number are required. The reference_number identifies an invoice, account or specific transaction and has a maximum length of 16 characters. The gateway limits and normalises this value to Latin letters, numbers and spaces.

Visa also requires the sender’s country, address and city. If these fields are omitted from the sender object, the corresponding billing address values are used. For Visa transactions involving Canadian-issued cards, state is also required and falls back to the billing address if omitted.

For Mastercard Funding Transactions, type identifies whether the sender is a natural person (natural) or a legal entity (legal). If omitted, natural is assumed. When the sender is a legal entity, name is required and represents the organisation’s name. For natural persons, name is optional for Mastercard.

Visa ignores sender.type. See Sender types for further details.

Sender types

Set funding.sender.type to identify whether the sender is a natural person or a legal entity for Mastercard Funding Transactions.

VALUE	DESCRIPTION
`natural`	The sender is an individual. This is the default when `type` is omitted.
`legal`	The sender is a legal entity, such as a company or organisation. The sender’s `name` is required and represents the organisation’s name.

For Visa AFTs, funding.sender.type is ignored. However, funding.sender.name remains required.

The Mastercard type values, default behaviour and name requirements are documented in the API reference.

Receiver details

The funding.receiver object contains information about the person or organisation receiving the funds. Supported fields include first_name, last_name, type, country, account_number, account_number_type, address, address2, state, city and zip_code. The street_name field is also supported for WPF Create requests only.

The receiver’s country (ISO 3166-1 alpha-2) and account_number are required for both Visa and Mastercard funding transactions.

For Visa AFTs, last_name is required regardless of the receiver type, and receiver.type is ignored. Additional address fields may be required depending on the card’s issuing country:

address is required for cards issued in Canada, Australia, New Zealand and specified South Pacific territories.
address2 is required for Visa cards issued in Ukraine, Canada, Nicaragua and Colombia.
state and city are required for Canadian-issued cards.
zip_code is required for Visa cards issued in Ukraine and Canada.

For Mastercard Funding Transactions, type identifies whether the receiver is a natural person (natural) or a legal entity (legal). If omitted, natural is assumed. For natural persons, provide the receiver’s first_name and last_name. For legal entities, use first_name for the organisation’s name; last_name is optional.

Mastercard also requires account_number_type to identify the type of receiving account. This parameter is not required for Visa. See Receiver account types below.

Receiver account types

For Mastercard Funding Transactions, specify the type of receiving account using funding.receiver.account_number_type. This parameter is required for Mastercard but not for Visa. If the card scheme is not known when creating the request, you can include this parameter for both schemes.

VALUE	DESCRIPTION
`rtn_and_bank_account_number`	Routing Transit Number and Bank Account Number
`iban`	International Bank Account Number
`card_account`	Card Account
`email`	Email Address
`phone_number`	Phone Number
`bank_account_number_and_bic`	Bank Account Number and Business Identifier Code
`wallet_id`	Wallet ID
`social_network_id`	Unique Identifier for Social Network Application
`other`	Any other type

Purpose of payment

For Visa Account Funding Transactions (AFTs), use the purpose_of_payment parameter to identify the purpose of the transfer. This parameter is provided directly within the payment_transaction object, outside the funding object.

It is required for Visa cards issued in Argentina, Bangladesh, Chile, Colombia, Egypt, India, Mexico and Saudi Arabia. An incorrect purpose of payment may result in the transaction being declined by the issuer.

Provide a purpose_of_payment value that matches the transaction, using either a supported descriptive value (e.g. cash_management_transfer) or its Visa code (ISCASH). If omitted, it defaults to payment_to_savings_retirement_account (ISSAVG), which may not reflect the actual transfer.

See the API reference’s Purpose of Payment Codes section for the complete list of supported purpose of payment codes.

Example request

Visa and Mastercard funding transactions use the same general request structure, but their required parameters differ. Visa requires business_application_identifier, while Mastercard requires identifier_type. You can include both parameters when the card scheme is not known in advance, such as when using the Web Payment Form (WPF). The following Processing API Sale example uses a Visa card, so only business_application_identifier is included.

The following example demonstrates a Visa account-to-account funding transaction. It includes sender and receiver details and the Visa-specific purpose_of_payment parameter. Some fields are included for illustration and may not be required for every issuing country. The UK billing, sender and receiver addresses do not indicate the card’s issuing country.

The following is an example request:

<payment_transaction>
  <transaction_type>sale</transaction_type>
  <transaction_id>aft-visa-001</transaction_id>
  <remote_ip>203.0.113.10</remote_ip>
  <amount>2500</amount>
  <currency>GBP</currency>
  <card_holder>Oliver Bennett</card_holder>
  <card_number>4200000000000000</card_number>
  <expiration_month>12</expiration_month>
  <expiration_year>2030</expiration_year>
  <cvv>123</cvv>
  <customer_email>oliver.bennett@example.com</customer_email>
  <billing_address>
    <first_name>Oliver</first_name>
    <last_name>Bennett</last_name>
    <address1>10 King Street</address1>
    <zip_code>SW1A 1AA</zip_code>
    <city>London</city>
    <country>GB</country>
  </billing_address>
  <purpose_of_payment>cash_management_transfer</purpose_of_payment>
  <funding>
    <business_application_identifier>account_to_account</business_application_identifier>
    <sender>
      <name>Oliver Bennett</name>
      <type>natural</type>
      <reference_number>AFTVISA001</reference_number>
      <country>GB</country>
      <address>10 King Street</address>
      <city>London</city>
    </sender>
    <receiver>
      <first_name>Oliver</first_name>
      <last_name>Bennett</last_name>
      <type>natural</type>
      <country>GB</country>
      <address>10 King Street</address>
      <city>London</city>
      <account_number>oliver.bennett@example.com</account_number>
      <account_number_type>email</account_number_type>
    </receiver>
  </funding>
</payment_transaction>

Example response

The following is an example response:

<payment_response>
  <transaction_type>sale</transaction_type>
  <status>approved</status>
  <transaction_id>aft-visa-001</transaction_id>
  <unique_id>8a8294498b3e6876018b48eaf41d1ca3</unique_id>
  <amount>2500</amount>
  <currency>GBP</currency>
</payment_response>

This is an illustrative minimal response. Actual responses may include other standard transaction fields.

Was this page helpful?