How to Use B2B Virtual Account Payment Method for Buyers Using VANs

B2B Virtual Account Payment Method

How to Use B2B Virtual Account Payment Method for Buyers Using VANs

Overview

Issuers, buyers, processors, third party payment providers, and Travel agencies, can use the B2B Virtual Account Payment Method APIs. By using these endpoints, you can automate the process of paying your suppliers using TSYS Virtual Account Numbers (VANs). These APIs can also be used for requesting accounts with authorization controls and using the accounts for processing the payment yourself.

You can use VANs to handle payments for buyers associated with Visa and Mastercard issuers as this feature offers a single platform for both brands. The VANs are stored in a proxy pool(s) available to be used for making a payment. The VANs are held in an inactive status in the proxy pool until it is assigned to a payment to prevent unauthorized use. The proxy pool will be automatically replenished with VANs based on the configured settings.

The VPA system sets the Exact Match and Spend Velocity authorization rules on VANs which are picked for making a payment. The authorization rules are set on the VAN at the TSYS VPP system.

Account Management

The majority of the Account Management Web Services are not applicable for buyers using VANs. These include Virtual Card Requisition, Manage Payment Controls, List Payment Controls, and Get Account Status.

These API calls are supported for VANs:

Implementation Notes:

See the Rules and Overrides table for a list of Request Virtual Account API Rules and Overrides to support buyers using VANs.

All settlements that come through will be matched with the payment requisition information.

Single Use Account Maintenance

SUA Get Account Status API- This endpoint is not applicable for VANs. Proxy pools set up for VANs are replenished automatically based on the configured settings.

Create Proxy Pool API - You can use this endpoint to create a proxy pool. Accounts are requisitioned from the TSYS vault within 15 minutes of the pool being created. The full 16 digit funding account must be provided (or the default funding account will be used, if applicable).

Update Proxy Pool API - You can use this endpoint to update the proxy pool settings. Note that if accounts have already been loaded into the pool, only proxy features such as minimum available accounts and reorder count can be updated.

Delete Proxy Pool API- You can use this endpoint to delete a proxy pool, but only if no accounts have yet been loaded into the pool. Due to the fact that accounts are loaded within 15 minutes of being loaded, this likely is not applicable.

Get Proxy Pool API - You can use this endpoint to view the current parameters and status of an existing proxy pool, including the number of available accounts that can be used for a payment and total number of accounts in the pool.

Manage Proxy API—You can use this endpoint only to delete a VAN. If a VAN becomes compromised, it can be deleted using this endpoint.

Deleting a VAN results in the following:

  1. All payments attached to the VAN are canceled.
  2. The secure link in any outstanding payment notification emails is disabled.
  3. The authorization rules set on the account are removed.
  4. The VAN status is changed to canceled and the VAN expiration date is set to the current date.
  5. The settlement expiration date of the VAN is set to the current date plus the number of settlement days configured at the bank level. The settlement expiration date is the last day that prior authorizations on a VAN can be settled.

Note: If the action type is not delete, this request will be rejected.

Process Payments

Authorization controls are mandated for Payment Instruction. The Spend Velocity (up to payment) rule is applied to all VANs when used to make a payment. Additionally, the Exact Match rule is also applied to improve the reconciliation process.

VAN Expiration Date Logic

Each time you make a payment and a VAN is selected, the VAN will receive a new expiration date. The VAN expiration month will be the payment instruction or requisition expiration month. The VAN expiration year is configured during implementation. The configured years will be added to the current year to determine the VAN expiration year. This is applicable to both payment instructions and payment requisitions.

For example, if the payment expiration date is set to October 1, 2019, and the VAN expiration year is configured for 3 years, the VAN expiration date will be set to 10/22. This will eliminate the risk of declined transactions because of an expired VAN. This also ensures that each payment has a unique CVV2 value.

Supplier

Buyer Management

Create Buyer API - You can use this API to create a new individual buyer in VPA. Refer to the Buyer Setup Details page for in depth details on the information required. The vanconfig section is required and will include the buyer's TSYS Processor information, such as ADM Option and FCS Bank ID.

Update Buyer API - You can use this API to update an individual buyer in VPA. Refer to the Buyer Setup Details page for in depth details on what information is allowed to be updated.

Get Buyer Details API - You can use this API to view all parameters of an individual buyer in VPA. Refer to the Buyer Setup Details page for in depth details on what information is required.

Create Template API - You can use this API to create a new template (up to 20 per issuer) that can be used to create new buyers in VPA. A template is used when configurations are consistent from buyer to buyer so can be established upfront. Once created, the Create Buyer API is used to create the individual buyer, significantly minimizing the fields required for setting up individual buyers. Refer to the Buyer Setup Details page for in depth details on what information is required.

Update Template API - You can use this API to update the parameters of a template. There is a "sync buyer" option to only make the changes for future buyers associated with the template, or to update any existing buyers using that template. Refer to the Buyer Setup Details page for in depth details on what information is allowed to be updated.

Get Template API - You can use this API to view all parameters of a template.

Request Virtual Account Reconciliation Extract File Format

This is the file specification and layout for the Request Virtual Account Reconciliation Extract File. All settlements that come through originating from the Request Virtual Account API will be matched with the payment requisition information, including the requisition status. The user has the ability to include up to 50 optional fields in the original requisition request, and it will be passed through to the reconciliation file. The file is available daily, weekly, or monthly and can be configured through the Visa Implementation team. Based on your delivery configurations, you will receive an empty file with headers if there are no settlements for the time period.

Note: There are three available statuses for the requisition: Active, Complete, and Delete.

Active "A" - This indicates if a settlement is attributed to an open requisition. The settlement is received within the requisition validity dates.

Complete "C" - This indicates if the settlement was received after the requisition validity end date.

Delete "D" - Deleted - The settlement was received for a deleted requisition.

Request Virtual Account Reconciliation Extract File Format Specification

FIELD NAME FIELD SPECIFICATION(TYPE) FILE SPECIFICATION\n(LENGTH/FORMAT) FIELD DESCRIPTION DATA SOURCE
Bank ID Alphanumeric 15 The bank ID is the bank identifier as defined in Visa Payables Automation. Derived from the client ID sent in the web service request
Buyer ID Alphanumeric 25 The buyer ID is the buyer identifier as defined in Visa Payables Automation. Derived from the buyer ID sent in the web service request
Account Number Numeric 16 The VAN identifies the account for the defined requisition parameters. If the masking feature is enabled, the VAN will be masked per the specifications in the Buyer Profile. The VAN picked from the proxy pool requested in the web service request
Proxy Pool ID Alphanumeric 19 Unique identifier of the single use proxy pool Web service request
Requisition Start Date Date Buyer Date format Account validity start date. This is based on the date format set up in the Buyer Profile. Web service request
Requisition End Date Date Buyer Date format Account validity end date. This is based on the date format set up in the Buyer Profile. Web service request
Time Zone Alphanumeric 12 The timezone used in the payment instruction. This will be in the format of UTC-6, UTC+8, etc. Note: For VPP/buyers using VANs, the timezone should reflect EST. Web service request
Billing Amount Decimal 18, 2 The billing amount of the transaction. This will be transaction amount converted to the billing currency. BASE II Settlement
Billing Currency Code Alphabetic 3 The billing currency of the transaction. ISO-alpha currency code. BASE II Settlement
Transaction Amount Decimal 18, 2 BASE II value for posted and settled transaction; Value reflects decimal point followed by two values; dash or "-" sign indicates negative value. BASE II Settlement
Transaction Currency Code Alphabetic 3 This is the currency code in which the transaction occurred. BASE II Settlement
Merchant Category Code Alphanumeric 4 This is the merchant category code associated with the transaction. BASE II Settlement
Merchant Name Alphanumeric 50 This is the merchant name where transaction was processed. BASE II Settlement
Merchant City Alphanumeric 50 This is the city that corresponds to the merchant name/location where the transaction was processed. Note: This field may contain the merchant's phone number. BASE II Settlement
Merchant Country Code Alphanumeric 50 This is the country code that corresponds to the merchant name/location where the transaction was processed. BASE II Settlement
Purchase ID Alphanumeric 75 The purchase ID passed in the posted and settled transaction. (May not be present in all cases.) Only include the purchase ID if the merchant provides it. BASE II Settlement
Settlement Date Date Buyer Date format BASE II value for posted and settled transactions. This is based on the date format set up in the Buyer Profile. BASE II Settlement
Credit Debit Indicator Alphabetic 1 This indicates whether the transaction is C- Credit or D - Debit. BASE II Settlement
Transaction Reference Number Alphanumeric 24 Transaction reference number passed for the posted and settled transaction. BASE II Settlement
Requisition Status Alphabetic 1 This is the status of the requisition. There are 3 possible values. Valid values are: A - Active - The date when the settlement occurred is within the requisition validity dates. C - Complete - The settlement was received after the requisition validity date. D - Deleted - The settlement was received for a deleted requisition. VPA System
Optional Field Name 1 Alphanumeric 50 Optional Field Name 1 sent in the web service request. Web service request
Optional Field Value 1 Alphanumeric 100 Optional Field Value 1 sent in the web service request. Web service request
Optional Field Name 50 Alphanumeric 50 You can enter up to 50 optional field names. These cannot exceed 50 characters. Web service request
Optional Field Value 50 Alphanumeric 100 You can enter up to 50 optional field values. These cannot exceed 100 characters. Web service request