Add Funding Account

[waelzhang]

I am a programmer in a bank. We want to use the Virtual Account Payment Method to provide our bank customers with the function of applying for Virtual cards.  When I read the Add Funding Account Api, the link was:  https://developer.visa.com/capabilities/vpa/reference#tag/Account-Management-service/operation/Add%2...  1%20-%20Latest;  

I can't understand the sentence "This API is applicable only to buyers who use VIP Pseudo Accounts or VPP VANs";  I have created a Buyer through the Create Buyer interface. May I call the Api of Add Funding Account to associate the fund Account with the Buyer I created?  

[jenn_kh]

Thank you for your question, @waelzhang! An agent will get back to you as soon as possible. In the meantime, if any community member knows the solution, please reply here! -Jenn

[API_Products · Accepted solution]

Hi @waelzhang,

The Add Funding Account API is used if the issuing financial institution issues VIP pseudo accounts or TSYS VPP VANs. These account types are both “tokens” which means there is a parent funding account (or multiple) for a corporate and children pseudo accounts provisioned off of the parent account. The parent funding account comes from the processor. The individual pseudo accounts given to the end cardholder come from a token vault.

VIP pseudo accounts are Visa Commercial’s version of a token. A parent account for the corporate is generated from the Issuer’s BIN at their processor and the children pseudo accounts are generated from Visa’s token vault. They are generated off of a Visa-owned BIN range that is assigned to the Issuer.

TSYS VPP VANs are TSYS’ version of a token and are very similar. A parent account for the corporate is generated from the Issuer’s BIN at TSYS and the children pseudo accounts are generated from TSYS’ token vault. They are generated off of a TSYS-owned BIN range that is assigned to the Issuer.

The Add Funding Account API is used to add a parent account to a company’s profile in the end system. Once the Funding Account is associated with the company, the Create Proxy Pool API is used to create a pool of tokens.

Please not that in order to use these account types and APIs in production, the issuer must be signed up for Visa Payables Automation, and must complete a token certification project, if they have not already.

[waelzhang]

hi,DianaTran-Yee!

I'm glad to receive your reply, I don't fully understand VIP pseudo Acconts.

Is it the virtual card I will apply for?

I eventually want to offer our bank customers the ability to apply for a virtual card, and I want to know if a virtual account is a fake account.

I'm going to follow these steps using APIs to apply for virtual cards for our bank customers.

1, /vpa/v1 / buyerManagement/buyer/create

Then I get a buyerId registered with VISA;

2, /vpa/v1/accountManagement/fundingAccount/create

I provide a buyerId from the previous step and a full 16-bit fund account, and then I think the user I created is associated with the fund account;

3, /vpa/v1 / proxy/CreateProxyPool

I provide the buyerId and custom proxyAccountNumber from the previous step, and I get a proxyAccountNumber registered with VISA

4, /vpa/v1 / accountManagement/VirtualCardRequisition

I provide buyerId, employeeId, proxyPoolId, and then I have an accountNumber

Don't know this step right? Please give me some instructions. Thank you very much!

[API_Products]

Hi @waelzhang,

I'll take a look and get back soon. 

[API_Products · Accepted solution]

Hi @waelzhang,

Pseudo accounts are real accounts that are used to transact on – they are 16 digit accounts with expiration date and 3 digit security code.  They are the children accounts generated off of a parent funding account.  The parent funding account comes from the processor and is on the Issuer’s BIN.  Child pseudo accounts are generated from the token vault and are from a Visa-owned BIN.  You must have an issuer or a BIN sponsor to use these APIs.   An issuer is key for these APIs as they have to complete the tokenization/ pseudo account project and provide the parent account for each buyer/company.

In step 1, you provide the company information, including the buyer ID, so that we can set up the buyer in our system. The Issuer usually provides the company / buyer ID that is configured at the issuer’s processor.  Step 2 is correct – you provide the Company ID and a 16 digit funding account (PAN) which is usually from the issuer’s processor. This associates the funding account with the buyer.  In Step 3, you provide the buyer ID and funding account and then you tell us what to name the proxy pool you will create.  Pseudo accounts are then loaded into this pool. This is the source of the accounts when an account is requested. In Step 4, please use RequestVirtualAccount, and NOT VirtualCardRequisition.  This is the step where you request an account with specified controls and we pull one out of the proxy pool and return the 16 digits and expiration.  Step 5 is usually needed to get the 3 digit security code. You send the 16 digit virtual / pseudo account and expiration date returned in step 4, and we return the 3 digit security code.

[blitzy_rotashet]

So, the buyer can top-up their various Pseudo accounts with the amount they are willing to add to the card right?

[I_Doroteo3]

Hi @blitzy_rotashet. , 

The credit limit and expiration date are defined at implementation, and the pseudo accounts inherit the same credit limit as the parent account. Users can set account controls on each pseudo account, such as exact match rules, spend velocity rule, etc. which is what will control how much the user can spend and limit spending on the card to only what is allowed.   

Thanks, 

Illana