General Guidelines

This guide provides software developers with specific integration guidelines unique to each certified payment service provider and Value-Added Service (VAS) supported by the NAB Velocity Managed Commerce Services Platform. This information should be referenced during development to ensure smooth application certification.

The following guidelines apply to all NAB Velocity certified service providers when processing Bankcard (BCP) transactions:

Address Verification Service (AVS) IIAS and Healthcare Card Processing
Balance Inquiry (Prepaid Credit Cards) Level 2/3 Data
Bankcard Processing Rules (By Industry) MasterCard SecureCode (MCSC)
Cardholder Activated Transactions Misuse Fees
Card Verification (CV) Partial Approvals
Check 21 / POP PIN Debit Processing
Commercial Card Processing Pinless Debit
Deferred Payments Recurring Payments
EBT Soft Descriptors
Host Capture vs. Terminal Capture Transaction Amount Tolerances
Installment Payments Verified-by-Visa (VbV)

Bankcard Processing Rules (By Industry)

In addition to the general integration guidelines described in this section, the following Bankcard Processing (BCP) rules apply to each of the four supported payment industries—Retail, Restaurant, eCommerce, and Mail Order/Telephone Order (MOTO).Retail Processing RulesRetail environments include card-present and card-not-present transactions. When processing a card-not-present Retail transaction using CWS, BankcardTransactionDataDefaults.CustomerPresent should be set to “Present”.Note: The CustomerPresent enumeration does not include a value for "NotPresent". As a result, the manner in which Retail card-not-present transactions are processed depends on the merchant's account with their service provider as well as the specific functionality supported by the merchant's payment application.The following card-specific requirements must be followed to obtain the best interchange rate for Retail transactions:Restaurant Processing RulesRestaurant environments include card-present and card-not-present transactions. When processing a card-not-present Restaurant transaction using CWS, BankcardTransactionDataDefaults.CustomerPresent should be set to “Present”.Note: The CustomerPresent enumeration does not include a value for "NotPresent". As a result, the manner in which Retail card-not-present transactions are processed depends on the merchant's account with their service provider as well as the specific functionality supported by the merchant's payment application.The following card-specific requirements must be followed to obtain the best interchange rate for Restaurant transactions:eCommerce Processing RulesElectronic Commerce (eCommerce) environments are classified as those environments where the card and/or cardholder are not physically present at the time of purchase and transaction requests are performed over the Internet. Making credit card payments for online purchases via a merchant website is one example of an eCommerce transaction. When processing a card-not-present eCommerce transaction using CWS, BankcardTransactionDataDefaults.CustomerPresent should be set to “Ecommerce”.Cardholders can only be billed for items actually shipped. If an item ordered is not in stock, the settled transaction should only be for the amount of the items in stock, and therefore ready for shipment.The following card-specific requirements must be followed to obtain the best interchange rate for eCommerce transactions:Mail Order/Telephone Order (MOTO) Processing RulesMail Order/Telephone Order (MOTO) environments are classified as those environments where the card and/or cardholder are not physically present at the time of purchase. For example, a merchant accepting credit card payments via mail or telephone. When processing a card-not-present MOTO transaction using CWS, BankcardTransactionDataDefaults.CustomerPresent should be set to “MOTO”.Cardholders can only be billed for items actually shipped. If an ordered item is out of stock, the settled transaction should only be for the amount of the items in stock, and therefore ready for shipment.The following card-specific requirements must be followed to obtain the best interchange rate for MOTO transactions:  Address Verification Service (AVS)Address Verification Service (AVS) provides merchants with additional information concerning the authentication of a particular transaction. Supporting AVS has several benefits for the merchant. By requesting and verifying the cardholder’s address allows the merchant better fraud protection when the cardholder is not physically present at the time of purchase. AVS may help to prevent chargebacks if the merchant can identify a fraudulent transaction prior to completing the purchase.The following general requirements should be considered:

  • AVS is provided by Visa, MasterCard, American Express, and Discover Cards.
  • Addresses to P.O. Boxes are accepted if it's the cardholder’s billing address.
  • When processing transactions in MOTO or eCommerce card-not-present environments, Visa will assess a lower interchange rate if AVS is requested. A match is not required.
  • When processing transactions in card-present Retail environments, merchants that must manually key an account number due to a bad magnetic stripe will receive a lower interchange rate if they request (and receive) verification of the cardholder’s zip code. A match is required.

Account Status CheckCredit card payment brands such as Visa and MasterCard allow merchants to validate a cardholder’s account prior to proceeding with a payment transaction. This is commonly referred to as an account status check. Account status checks can be used for both Address Verification (AVS) and Card Verification (CV).$1 Status Check (CWS Authorize)

  • Visa allows the $1.00 status check for Automated Fuel Dispensers (AFD), select lodging, and deferred payment transactions only.
  • MasterCard allows the $1.00 status check for Automated Fuel Dispensers (AFD) only.
  • Refer to Visa Authorization Misuse Fees and MasterCard Reversal Mandate for more information.

$0 Status Check (CWS Verify)

  • Visa allows merchants requiring verification of the cardholder’s account to utilize the $0.00 status check.
  • When submitting a $0.00 authorization request, NAB Velocity requires Address Verification Service (AVS) data. Postal code is required, street is optional.
  • The merchant may also submit Card Verification Data (CV) for validation in this same authorization request.
  • Refer to Visa Authorization Misuse Fees and MasterCard Reversal Mandate for more information.

Visa CPS/MasterCard Merit Requirements (Manually Keyed Transactions)

Visa supports multiple interchange rates for transactions that are manually keyed. The specific rates are differentiated based on the presence of the card at the time of the transaction.CPS/Retail Key EntryIn order for a merchant to receive the best interchange rate on a manually keyed transaction in a card-present environment (Retail), a positive verification of the cardholder’s zip code is required. This interchange rate only applies to those transactions that are keyed due to the magnetic stripe being unreadable.For commercial cards, AVS is not required to qualify for the CPS/Retail Key Entered rate. If AVS is requested, all AVS responses are appropriate.CPS/Card-Not-PresentIn card-not-present environments (MOTO/eCommerce), Visa requires that AVS is attempted in order to receive the lowest interchange rate for this category. Both the cardholder’s address and zip code can be submitted for verification, or just zip code verification can be requested. This interchange rate is only allowed in MOTO environments.  Balance Inquiry (Prepaid Credit Cards)Prepaid credit cards are fixed value cards branded with a payment brand logo such as Visa, MasterCard, American Express, Discover, or JCB. Although these cards are sometimes referred to as “gift cards”, they should not be confused with proprietary stored value cards purchased by merchants and issued to customers for use only at that merchant’s location. Brand-issued prepaid card are meant to be accepted anywhere the brand is accepted and not limited to a particular merchant.Additional requirements for processing prepaid credit card transactions are listed below:

  • Prepaid credit card transactions flow through the normal credit card authorization process, just like non-prepaid credit cards, and can be processed in any industry.
  • The balance on prepaid credit cards can be verified by calling the CWS QueryAccount operation.
  • It is possible for prepaid cards to be issued under any BIN managed by a payment brand, not just a prepaid range. The identification of prepaid cards is at the discretion of the payment brand and/or issuer. Prepaid cards can be labeled by the issuer as credit or debit cards.
  • Prepaid cards are not covered under brand tolerance rules. All authorizations on prepaid cards must be equal to or less than the available balance at the time of the authorization or the merchant may be subject to chargebacks. Merchants who allow the addition of tips or other offline adjustments should be especially aware of this fact.
  • If the card issuer returns the card's remaining balance and the purchase amount does not exceed the card's balance, the remaining balance after the purchase will be returned in BankcardTransactionResponse.FinalBalance. A negative balance will be returned as zero.
  • Displaying balances on a terminal screen or printing them on the customer receipt are optional for all brands except MasterCard. MasterCard requires that balances, when available, are either displayed on a screen or printed on the customer’s receipt.
  • Providing the opportunity for the customer to view the account balance on a customer-facing terminal screen or on a printed receipt can provide a more positive customer experience. Currently, only MasterCard has mandated this feature, but it is expected to be required by other brands in the future.

Cardholder Activated Transactions

Cardholder Activated Transactions (CAT), also referred to as unattended terminals, are self-service devices that dispense goods to a customer without the presence of a sales clerk or attendant. These devices read, capture, and transmit card information as a result of the cardholder's direct interaction with the device in an unattended environment.When processing transactions in unattended environments, the card must be present and the card data must be electronically captured. Manual keying of the card information is not allowed.Transactions that originate from an unattended device may or may not receive the best interchange rate from the payment brand, depending on each of the card association's rules. Although the best interchange rate may not be obtained, not identifying the transaction properly will reduce the merchant's chargeback protection in the event that the cardholder or issuer disputes the charge.CWS transactions initiated at an unattended terminal must be identified as follows:

  • BankcardTransaction.ApplicationConfigurationData.ApplicationAttended must be set to “Unattended”.
  • BankcardTransaction.ApplicationConfigurationData.HardwareType must be set to “TicketMachine” or “InitiatedCAT”.

Card Verification (CV)

Visa and MasterCard implemented Card Verification Values (CVV) and Card Verification Codes (CVC2) to combat fraud. These values are the result of an algorithm and are encoded on the magnetic stripe of the card. Any alteration of the data elements read from the magnetic stripe prior to sending for authorization will cause the value not to match when the issuer reruns the algorithm at the time of authorization.Transactions that are determined to be non-compliant will result in higher interchange fees and forfeiture of chargeback protection. Any point-of-sale (POS) device submitting non-compliant transactions will be identified as such, and all transactions processed will automatically receive a higher interchange rate and lose chargeback protection. In order to be in compliance, a POS device must send the entire unaltered contents of the magnetic stripe (Track 1 or Track 2 data). The definition of a magnetic stripe by Visa/MasterCard is everything after (but not including) the start sentinel (% or ;) and up to (but not including) the end sentinel (?) and LRC check character. The maximum length without the starting and ending sentinel of the LRC character is 77 for Track 1 data and 37 for Track 2 data.Authorization requests containing altered Track 1 or Track 2 data will be flagged as "Not Compliant" by Visa and MasterCard resulting in the merchant paying the highest transaction rate and forfeiture of chargeback protection. Both associations monitor non-compliant transactions and assess fines and penalties to merchants that are not in compliance.Refer to White Listed Credit Card Data for certification testing information related to Card Verification.Enhanced Card Verification DataIn recent years, the card associations have implemented enhanced security programs that assist merchants in card-not-present environments by verifying that the cardholder has physical possession of the card. This data is commonly referred to as Card Verification Data (CVD), and can take many forms:Some additional considerations regarding CVD:

  • Most card associations and issuers do not validate CVD when the card is swiped. As a result, no response code will be returned in the transaction response.
  • Although enhanced CVD is considered optional, providing this data ensures additional fraud protection for all manually keyed, card-not-present authorization requests.
  • Visa, MasterCard, and Discover provide a CVD result code on every transaction if CVD is entered. The CVD response can be used by the merchant to determine if the cardholder has possession of the card at the time of the sale. By using the CVD response code to determine the legitimacy of the transaction, the merchant can reduce the potential of fraudulent transactions being processed, therefore reducing merchant chargeback losses.
  • American Express merchants must be registered with AMX in order to perform the CID match. For registered merchants, if the CID value matches, the transaction is approved. For merchants not registered with AMX for this service, CID matching can still be requested, but matching will not be performed. If there is no CID match for proprietary American Express cards, the transaction is declined. For American Express cards issued by other banks, they may return a CID response value.
  • The CVD response does not need to be a match for a transaction to be approved. It is the merchant’s responsibility to accept or reverse an approved transaction when the CVD response is not a match.

Check 21 / POP

The Point-of-Purchase method of payment is for purchases made for goods or services in person by the consumer. These are non-recurring debit entries. A check reading device must be used to capture the routing number, account number, and check number from the source document (check). The source document cannot be previously used for any prior POP entry, and the source document must be voided and returned to the customer at the point-of-purchase. In addition a signed receipt must be obtained at the point-of-purchase and retained for 2 years from the settlement date. The "Authorization Requirements" section in the Authorization Gateway Specification document contains additional information on the receipt requirements.

Commercial Card Processing

Visa, MasterCard, and American Express offer businesses with a card platform that provides additional reporting that allows them to monitor user activity for those cards. Each of these card brands are referred to as commercial cards. Visa and MasterCard categorize their commercial cards as Corporate, Business, and Purchase/Purchasing, while American Express refers to their commercial card as Corporate Purchasing.In order to provide this reporting to these businesses, merchants must submit additional data with each transaction. If submitted with the transaction, the merchant may qualify for lower consumer card interchange rates. If not submitted, both Visa and MasterCard assess higher commercial interchange rates based on whether the card was swiped or keyed, timeliness of the deposit, etc. Level 2 and Level 3 data is not required to be submitted on Travel & Entertainment transactions in order for them to receive the best interchange for their industry categories. However, when processing Level 3 data, Level 2 data must be provided as well.Visa RequirementsMerchants should submit as many of the data elements as possible for their business model. Software companies should make every field available for merchant use, as the requirements may differ from merchant to merchant. In order to meet Visa Level 2 data requirements, the sales tax must be greater than $0.00, and the Tax Flag must indicate that tax is present. The value must fall within 0.1% and 22% for Visa of the total transaction amount. The host will not edit (or require) the Sales Tax Amount to be within this range. However, if it is not within this range, the transaction will not qualify for the best interchange rate allowed on these cards.Tax Exemption must be properly identified in the Local Tax Flag field. If the transaction tax amount equals $0.00, the Local Tax Flag must indicate that the transaction is tax exempt. Visa no longer allows Tax Exempt transactions to qualify for the best interchange rate.For Visa Canadian merchant locations, the PST (Provincial Sales Tax), QST (Quebec Sales Tax), GST (Goods & Services Sales Tax), or HST (Harmonized Sales Tax) may be provided on Business and Purchase Cards.Visa Purchase Cards can be identified by BIN range, while Corporate and Business Cards cannot be identified by BIN range.At non-petroleum merchant locations, Visa Fleet cards are treated as Purchasing Cards.MasterCard RequirementsIn order to meet MasterCard Face-to-Face Commercial Data Rate II data requirements, the sales tax amount must be greater than $0.00 and the tax flag must indicate that tax is present. The value must fall within 0.1% and 30% of the total transaction amount. The host will not edit (or require) the Sales Tax Amount to be within this range. However, if it is not within this range, the transaction will not qualify for the best interchange rate allowed. MasterCard does not require a tax amount for fuel transactions; therefore, a zero tax amount will continue to qualify for Commercial Face-to-Face and Data Rate II interchange categories.MasterCard removed the tax edit resulting in transactions with zero or no tax to be eligible for Commercial Face-to-Face and Data Rate II rates for the following Merchant Category Codes (MCC):

  • 4111 – Transportation
  • 4131 – Bus Lines
  • 4215 – Courier Services
  • 4784 – Bridge and Road Fees
  • 8211 – Schools
  • 8220 – Colleges
  • 8398 – Charitable Organizations
  • 8661 – Religious Organizations
  • 9211 – Court Costs
  • 9222 – Fines
  • 9311 – Tax Payments
  • 9300 – Government Services
  • 9402 – Postal Services

Transactions for the MCCs listed above can be submitted either with no tax or a tax amount between 0.1% and 30% of the transaction amount to be eligible for these rates.For MasterCard Canadian merchant locations, the GST (Goods & Services Sales Tax) or HST (Harmonized Sales Tax) may be provided on Business and Purchase Cards.MasterCard Purchasing, Corporate, and Business Cards are no longer able to be managed by BIN range.At non-petroleum merchant locations, MasterCard Fleet cards are treated as Purchasing Cards.American Express RequirementsFor American Express Purchasing Card Level 2, if the Customer Reference No, Tax Amount, and Destination Zip are submitted by the merchant, Chase Paymentech will submit that data to American Express to be considered for Level 2 qualification for conveyed merchants. American Express requires setup on their system for a merchant to support Level 2. Merchants should contact their American Express representative.American Express Corporate Purchasing cards are not limited to specific bin ranges and there is no identification of a corporate purchasing card in the response message. American Express identifies a Corporate Purchasing card during their settlement processes.  Deferred PaymentsDeferred payments are transactions for which billing occurs after delivery. Deferred payment transactions may be submitted to bill the cardholder for merchandise received within the past 90 days. The deferred transaction indicator allows issuers to identify these unique types of requests and provides information to assist customer service representatives in addressing issues related to disputes, chargebacks, and authorization holds. The deferred transaction indicator (value of the CWS BillPayment enumeration) is required in all transaction authorization and settlement messages.When supporting deferred payment transactions in CWS:

  • BankcardTransactionPro.InterchangeData.BillPayment must be set to “DeferredBilling”.
  • BankcardTransactionPro.InterchangeData.ExistingDebt must be set to “NotExistingDebt” unless the customer participates in the Visa Debt Repayment Program. Flagging a Visa transaction as existing debt will result in declines when not used properly.
  • BankcardTransaction.BankcardTransactionData.CustomerPresent must be set to “BillPayment”.

EBT
EBT Purchase (Food Stamp/Cash Benefits) - Restaurant/Retail Only
EBT Return (Food Stamp/Cash Benefits) - Restaurant/Retail Only
EBT Balance Inquiry (Food Stamp/Cash Benefits) - Restaurant/Retail Only
EBT Food Stamps Voucher Clear - Restaurant/Retail OnlyRequest XML:<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<ManageAccount
xmlns="http://schemas.abcommerce.com/CWS/v2.0/TransactionProcessing">
<sessionToken>PHNhbWw6QXNzZXJ0aW9uIE1ham9yVmVyc2lv</sessionToken>
<transaction
xmlns:ns1="http://schemas.abcommerce.com/CWS/v2.0/Transactions/StoredValue"
xsi:type="ns1:StoredValueTransaction">
<ns2:RelayResponseUrl
xmlns:ns2="http://schemas.abcommerce.com/CWS/v2.0/Transactions">https://www.freedonationkiosk.com/Notification.aspx</ns2:RelayResponseUrl>
<ns3:CustomerData
xmlns:ns3="http://schemas.abcommerce.com/CWS/v2.0/Transactions"
xsi:nil="true"/>
<ns4:ReportingData
xmlns:ns4="http://schemas.abcommerce.com/CWS/v2.0/Transactions">
<ns4:Comment
xsi:nil="true"/>
<ns4:Description
xsi:nil="true"/>
<ns4:Reference>3444444</ns4:Reference>
</ns4:ReportingData>
<ns5:Addendum
xmlns:ns5="http://schemas.abcommerce.com/CWS/v2.0/Transactions"
xsi:nil="true"/>
<ns1:TenderData>
<ns6:PaymentAccountDataToken
xmlns:ns6="http://schemas.abcommerce.com/CWS/v2.0/Transactions"
xsi:nil="true"/>
<ns7:SecurePaymentAccountData
xmlns:ns7="http://schemas.abcommerce.com/CWS/v2.0/Transactions"
xsi:nil="true"/>
<ns8:EncryptionKeyId
xmlns:ns8="http://schemas.abcommerce.com/CWS/v2.0/Transactions"
xsi:nil="true"/>
<ns9:SwipeStatus
xmlns:ns9="http://schemas.abcommerce.com/CWS/v2.0/Transactions"
xsi:nil="true"/>
<ns1:CardData>
<ns1:TrackData
xsi:nil="true"/>
<ns1:AccountNumber>093454540000001</ns1:AccountNumber>
<ns1:Expire>1215</ns1:Expire>
<ns1:Track1Data/>
<ns1:Track2Data/>
</ns1:CardData>
<ns1:CardSecurityData
xsi:nil="true"/>
<ns1:CardholderId
xsi:nil="true"/>
<ns1:ConsumerIdentifications
xsi:nil="true"/>
</ns1:TenderData>
<ns1:TransactionData>
<ns10:Amount
xmlns:ns10="http://schemas.abcommerce.com/CWS/v2.0/Transactions">150.00</ns10:Amount>
<ns11:CurrencyCode
xmlns:ns11="http://schemas.abcommerce.com/CWS/v2.0/Transactions">USD</ns11:CurrencyCode>
<ns12:TransactionDateTime
xmlns:ns12="http://schemas.abcommerce.com/CWS/v2.0/Transactions">2015-01-15T14:48:21</ns12:TransactionDateTime>
<ns13:CampaignId
xmlns:ns13="http://schemas.abcommerce.com/CWS/v2.0/Transactions"
xsi:nil="true"/>
<ns14:Reference
xmlns:ns14="http://schemas.abcommerce.com/CWS/v2.0/Transactions"
xsi:nil="true"/>
<ns1:EmployeeId>5</ns1:EmployeeId>
<ns1:IndustryType>Retail</ns1:IndustryType>
<ns1:CardRestrictionValue xsi:nil="true"/>
<ns1:EntryMode>Keyed</ns1:EntryMode>
<ns1:OperationType>Activate</ns1:OperationType>
<ns1:OrderNumber>12345</ns1:OrderNumber>
</ns1:TransactionData>
</transaction>
<applicationProfileId>17406</applicationProfileId>
<merchantProfileId>EBT 093014</merchantProfileId>
</ManageAccount>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>  

Host vs. Terminal Capture Platforms

To better understand how specific service providers will conduct their transaction settlement processing, it is important to understand the two types of service provider host platforms—Terminal Capture and Host Capture.Terminal CaptureTerminal Capture platforms process funds, referred to as transaction settlement, only when specifically instructed to do so. As a result, Terminal Capture hosts require end-of-day settlement of all authorizations, voids, returns, etc, processed throughout the day through a batching process in order to complete the funding process. Batching of all transaction records is accomplished through the creation and transmission of what's referred to as a settlement file.Terminal Capture services are convenient for merchants who make adjustments to original transaction amounts prior to capturing them for settlement.Host CaptureHost Capture platforms conduct automatic, end-of-day settlement processing for all transactions (with a CaptureState of 'ReadyForCapture') without requiring further action from the merchant. Transactions authorized throughout the day are recorded and stored in a database on the service provider’s processing host. In situations where a change to the original transaction amount is required after initial authorization (such as a partial authorization reversal), such changes must be transmitted to the service provider.Two primary conveniences of Host Capture platforms include:

  • Typically only a transaction ID and relevant metadata needs to be stored by the applicationsubsequent to the initial authorization.
  • Host Capture reduces the chance that merchants will be charged higher interchange rates due to failure to meet industry guidelines associated with prompt transaction settlement. Typically, the first downgrade (resulting in higher interchange rates) occurs 24 hours from the time of a transaction’s initial authorization. It is important to note that the "aging off" of a transaction is against Visa and MasterCard mandates. When using the operation flow of Authorize > Capture, it is best to capture within 24 hours. If a transaction is not captured after 7 days (aging off period), the application should Undo the original Authorize transaction and implement either Tokenization or some process to initiate the authorization process again.

Batch Release Support
Host Capture service providers that support batch release provide merchants with a manual method for settling transactions by triggering immediate processing of all captured transactions; resulting in merchant settlement and funding prior to the cut-off time established by the service provider.

If manual settlement is not triggered by the application within a 24-hour period, all captured transactions are settled automatically based on the settlement cut-off time established by the service provider.InterchangeInterchange are fees charged to merchants by the major card brands (Visa, MasterCard, American Express, Diners, and Discover) for processing Credit or PIN Debit transactions. This is a base component of the total fees paid by merchants. Interchange fees are assessed on a per-transaction basis.There are a number of factors that can impact interchange. Some of these factors include timeliness of settlement, completeness of transaction data, and industry data requirements such as AVS data for MOTO transactions and CVV data for eCommerce transactions.For additional guidance regarding Termnal Capture, Host Capture, batch release support, or interchange, contact your NAB Velocity Sales Engineer.  Inventory Information Approval System (IIAS) and Healthcare Card ProcessingOverviewFlexible Spending Arrangement (FSA) and Health Reimbursement Arrangement (HRA) accounts are used by employers who permit electronic reimbursement of medical expenses through the use of debit cards. Under the arrangement, the cardholder’s use of the card is limited to merchants and service providers with specific Merchant Category Codes (MCC) related to healthcare.The Inventory Information Approval System (IIAS) is a point-of-sale (POS) technology used by retailers that accept FSA debit cards that are issued for use with FSA, HRA, and Health Savings Accounts (HSA) in the United States.

  • Every item in the store's scanner database is flagged "yes" or "no" for FSA eligibility.
  • Prescription drugs are usually not in the main scanner database (though they may be made scannable by tying the pharmacy system into the scanners), but they are almost always FSA-eligible; therefore, the pharmacy department is often categorically flagged as FSA-eligible, the only department to be so treated.
  • At checkout, the scanner (for brick-and-mortar retailers) or shopping cart (for online retailers) keeps a separate total for those items that are "FSA-eligible".
  • If an FSA debit card is presented for payment, the scanner or shopping cart will charge the card, but for no more than the "FSA-eligible" total.
  • If there are other items in the order (or if the FSA debit card didn't pay for all eligible items), the scanner or shopping cart then demands another form of payment, such as cash, check, credit card or debit card, to pay for the remaining items.

Requirements

  • The merchant must make a record of each transaction available to the employer, or more commonly, to the employer's FSA or HRA provider. This can be done contemporaneously with the transaction, or it may be provided later if the Internal Revenue Service ever audits the employer.
  • There is no voice authorization on FSA/HRA cards.
  • The return of the cardholder's balance is not supported on FSA/HRA cards.
  • Merchants are encouraged, but not required, to support partial authorization for healthcare auto substantiation. Support for partial authorization is expected to reduce declines due to non-sufficient funds.
  • Card associations require that partial authorization-capable merchants support the reversal of authorizations.
  • In order to process health benefit transactions with Visa, the merchant must have a valid Merchant Verification Value. The Merchant Verification Value is assigned by Visa and is used to identify merchants that are participating in the program.
  • When supporting healthcare card transactions in CWS:
    • BankcardTransactionDataPro.IIASData.IIASDesignation must be set in order to qualify for IIAS processing. If this flag is not set, any amounts entered will be dropped and not forwarded to the processor.
    • BankcardTransactionDataPro.IIASData.HealthcareAmount is required and must contain the total amount of eligible healthcare items associated with the authorization.
    • Within BankcardTransactionDataPro.IIASData, PrescriptionAmount, VisionAmount, ClinicOtherAmount, and DentalAmount are optional fields that may be populated if the merchant chooses. These amounts do not need to total the HealthcareAmount, but they must not exceed HealthcareAmount.

Installment Payments

Installment payments are transactions for which a cardholder provides permission for the merchant to charge his/her account for a specified amount over a certain period of time. For example, if you were to purchase goods or services totalling $75.00 and you want to make 3 payments of $25.00. Installment transactions are card-not-present transactions requiring that Address Verification be obtained on a yearly basis.The initial transaction must indicate how the merchant obtained the cardholder's information (card-present, mail/telephone order, internet, etc). The initial authorization and settlement request should not contain the installment transaction indicator (value of the CWS BillPayment enumeration); only subsequent transactions will contain the installment transaction indicator. The installment transaction indicator is required for offline (voice authorized) transactions, but not on credit returns.When supporting installment payment transactions in CWS:

  • BankcardTransactionPro.InterchangeData.BillPayment must be set to “Installment”.
  • BankcardTransactionPro.InterchangeData.CurrentInstallmentNumber must be set to the correct installment payment number for the current payment.
  • BankcardTransactionPro.InterchangeData.ExistingDebt must be set to “NotExistingDebt” unless the customer participates in the Visa Debt Repayment Program. Flagging a Visa transaction as existing debt will result in declines when not used properly.
  • BankcardTransactionPro.InterchangeData.TotalNumberOfInstallments must be set to the total number of installments to be charged.
  • BankcardTransaction.BankcardTransactionData.CustomerPresent must be set to “BillPayment”.

Level 2 and Level 3 Data

Visa, MasterCard, and American Express offer businesses a platform that provides additional reporting to monitor user activity for their cards. Each of these card brands are referred to as commercial cards. Visa and MasterCard categorize their commercial cards as Corporate, Business, and Purchase/Purchasing, while American Express refers to their commercial cards as Corporate Purchasing.In order to provide businesses with such reporting features, merchants are required to submit additional data with each transaction. If submitted with the transaction, the merchant may qualify for lower consumer card interchange rates. If not submitted, both Visa and MasterCard assess higher commercial interchange rates based on whether the card was swiped or keyed, timeliness of the deposit, etc. Level 2 and Level 3 data is not required to be submitted on Travel & Entertainment transactions in order for them to receive the best interchange for their industry categories.Additional information about Level2/3 data:

  • Consumer cards do not support Level 2/3 data.
  • Level 3 cards can be processed as standard Level 1 cards.
  • When processing Level 3 data, Level 2 data must also be provided.
  • Not implementing support for Level 2/3 data (for cards that support Level 2/3 data) results in higher interchange rates charged to merchants.

For more information about the Level 2/3 data requirements for each card association, refer to Commercial Card Processing.  MasterCard SecureCode (MCSC)MasterCard SecureCode (MCSC) and Verified-by-Visa (VbV) are solutions designed to authenticate cardholders when making purchases online. Both of these programs require a merchant’s website (or cardholder) to have additional software that will allow interaction with the cardholder’s issuing bank at the time that the purchase is being made. This interaction will allow the cardholder to be authenticated at the time of the purchase. Once authenticated, the issuer will provide authentication data that must be passed to the host during the credit authorization process. The issuer will have an opportunity to validate the authentication data and respond accordingly.MCSC offers a mechanism for securing the Internet channel by strongly authenticating the cardholder at the point of interaction by providing a unique transaction-specific token that provides evidence that the cardholder originated the transaction. MCSC uses MasterCard’s Universal Cardholder Authentication Field (UCAF) infrastructure to communicate the authentication information among the cardholder, issuer, merchant, and acquirer.Recurring payments should include AAV data for the initial authorization request only. Merchants must not provide authentication data in recurring payment authorizations as these are not considered electronic commerce transactions by MasterCard and subsequently are not eligible for MCSC processing.For more detailed information regarding these programs, contact your NAB Velocity Sales Engineer.When supporting MCSC transactions in CWS:

  • If a token is obtained:
    • BankcardTransaction.BankcardTenderData.EcommerceSecurityData.TokenData is required and contains the token provided by the service.
    • BankcardTransaction.BankcardTenderData.EcommerceSecurityData.TokenIndicator is required and must be set to “UCAFWithData”.
  • If MCSC is supported, but the token could not be obtained or will not be sent with the transaction:
    • BankcardTransaction.BankcardTenderData.EcommerceSecurityData.TokenData will not be populated.
    • BankcardTransaction.BankcardTenderData.EcommerceSecurityData.TokenIndicator is required and must be set to “AttemptedCardUnsupported”, “AttemptedServiceUnavailable”, or “UCAFWithoutData”.

 Visa Authorization Misuse Fees and MasterCard Reversal Mandate

All approved and partially approved Visa and MasterCard authorizations must be reversed in the case of the cancellation of a sale by the cardholder or an authorization request submitted by the merchant in error. In support of this regulation, merchants and acquirers must process reversals immediately for authorizations cancelled by the cardholder or erroneously entered by the merchant. Failure to do so will result in fees being assessed on any unsettled transaction authorizations.Additionally, merchants who use the CWS Authorize operation to perform a $1.00 status check to validate the card must remember to reverse (void) the authorization to avoid being charged misuse fees by Visa and MasterCard. Service providers that support the CWS Verify operation can use the $0.00 status check to perform the same card validation without having to perform a reversal (void).To avoid such fees being assessed on unsettled authorizations, consider the following recommendations:

  • Perform a status check rather than a full authorization for transactions that will not be processed.
  • All card-present status check authorizations should be reversed within 24 hours.
  • All card-not-present status check authorizations should be reversed within 72 hours.
  • Visa also requires transactions to be cleared within 10 days of authorization for all MCC’s with the exception of T&E (Travel & Entertainment) segments which must be cleared within 20 days of the authorization regardless of the transaction date.
  • MasterCard lists the following MCCs as exceptions that are not required to adhere to the reversal mandate:
    • 3351-3441 (Car Rental Agencies)
    • 3501-3999 (Lodging)
    • 4411 (Cruise Lines)
    • 7011 (Lodging)
    • 7512 (Auto Rental Agency)

Refer to Address Verification Service (AVS) for more information.  Partial ApprovalsPartial Approvals (also referred to as partial authorizations) are Credit or PIN Debit authorizations where the requested amount is greater than the actual value of the account being debited. Not all card brands or card types support partial authorizations. Partial authorizations can be approved for regular cards, not just for prepaid products. It is the merchant’s responsibility to properly identify partial authorizations and to follow up with the cardholder to obtain payment for any remaining balances. The merchant should request another form of payment, and no further transactions should be processed against a card that has been partially-approved.When supporting partial approval payment transactions in CWS:

  • All credit transactions should have BankcardTransactionData.PartialApprovalCapable set to "Capable", indicating the merchant is capable of accepting partial approvals and handling the split tender transaction. A split tender transaction results when a partial authorization of the total purchase amount is returned to the device in the transaction response. The device must then prompt for payment of the remaining balance due on the sale. The cardholder uses a different form of payment for non-qualified items, such as another payment card, cash, or a check. The PartialApprovalCapable flag will default to “NotCapable” if not present.
  • If the cardholder is not capable of completing the transaction, the partial approval must be reversed by performing an Undo (Void). If the reversal is declined, a ReturnById/ReturnUnlinked (Return) can be used to remove the transaction from the cardholder’s account.
  • If the card's balance is less than the purchase amount and the card issuer supports partial approvals, the portion of the transaction request amount equal to the credit card's balance will be approved. BankcardTransactionResponse.StatusCode will contain "01" or “02” for partial approval, and BankcardTransactionResponse.Amount will contain the approved amount. The point-of-sale device must prompt for the split tender payment.
  • An issuer may indicate that a transaction has been partially approved if the full transaction amount depleted the card balance. In these cases, BankcardTransactionResponse.StatusCode will be returned as “02” (Fully approved, but the card was depleted). The request amount will match the authorization amount. Although the full amount of the transaction was approved, the transaction is categorized as a partial approval and any terminal that has not indicated it can support partial authorizations will receive a decline in these scenarios. No further transactions should be processed against a card that has been partially approved. If an authorization is approved for less than the request or fully approved, but the card balance is depleted, the host will return this in the response. Do not make adjustments over the authorization amount for prepaid cards, especially if the response indicates the card is depleted.

Note: Card associations require that merchants who are partial approval-capable must support the reversal of authorizations.  PIN Debit ProcessingPIN Debit transactions are primarily supported in card-present Retail and Restaurant environments. Most service providers require merchants to be approved during merchant account setup in order to process PIN Debit transactions.When supporting PIN Debit transactions in CWS:

  • Track 2 data, BankcardTransaction.BankcardTenderData.CardSecurityData.PIN and BankcardTransaction.BankcardTenderData.CardSecurityData.KeySerialNumber are required for all authorizations.
  • CashBackAmount is supported.
    • If CashBackAmount is not present then transaction will be just for Amount.
    • If CashBackAmount is present then Amount must be equal to Amount + CashBackAmount.
  • Note: When CashBackAmount is present, partial approval is not supported. CustomerPresent = Present and EntryMode = TrackDataFromMSR.

  PINless Debit Processing

  • Supported industries are MOTO and eCommerce.
  • Supported CWS Transaction Processing operations include AuthorizeAndCapture and Undo.
  • PIN-less Debit transactions are only supported for cardholder initiated transactions via a VRU (Voice Response Unit), Internet or the Call Center for bill payments for specific industry types. PIN-less Debit transactions will be routed to a Debit Network that supports PIN-less Debit transactions. If a Debit Network is unable to process the PIN-less Debit transaction, the transaction will receive a response code of “TRAN NOT ALLOWED” from FDMS.
  • The merchant must retrieve the On-line Debit Bin from FDMS. The On-line Debit BIN file is available to merchants every day. The various debit networks send updates to FDMS at different times during the week. FDMS updates the file on a daily basis. The On-line Debit BIN is received/retrieved on a weekly basis. The On-line Debit Bin File will be used to identify which cards can be submitted as PIN-less Debit transactions.
  • ServiceInformation.BankcardServices.Tenders.PINlessDebit must be set to "true", and all BankcardTransactionDataPro.PINlessDebitData.PayeeData elements are required.
  • All transactions must be keyed.

Request XML:<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<AuthorizeAndCapture xmlns="http://schemas.abcommerce.com/CWS/v2.0/TransactionProcessing">
<sessionToken>${Test 1: SignOnWithTokenResult}</sessionToken>
<transaction xsi:type="ns1:BankcardTransactionPro" xmlns:ns1="http://schemas.abcommerce.com/CWS/v2.0/Transactions/Bankcard/Pro">
<ns2:RelayResponseUrl xsi:nil="true" xmlns:ns2="http://schemas.abcommerce.com/CWS/v2.0/Transactions"/>
<ns3:CustomerData xmlns:ns3="http://schemas.abcommerce.com/CWS/v2.0/Transactions">
<ns3:BillingData>
<ns3:Name xsi:nil="true"/>
<ns3:Address>
<ns3:Street1>1400 16th st </ns3:Street1>
<ns3:Street2 xsi:nil="true"/>
<ns3:City>Denver</ns3:City>
<ns3:StateProvince>CO</ns3:StateProvince>
<ns3:PostalCode>80202</ns3:PostalCode>
<ns3:CountryCode>USA</ns3:CountryCode>
</ns3:Address>
<ns3:BusinessName xsi:nil="true"/>
<ns3:Phone xsi:nil="true"/>
<ns3:Fax xsi:nil="true"/>
<ns3:Email xsi:nil="true"/>
</ns3:BillingData>
<ns3:CustomerId>cust123x</ns3:CustomerId>
<ns3:CustomerTaxId xsi:nil="true"/>
<ns3:ShippingData xsi:nil="true"/>
</ns3:CustomerData>
<ns4:ReportingData xmlns:ns4="http://schemas.abcommerce.com/CWS/v2.0/Transactions">
<ns4:Comment>a test comment</ns4:Comment>
<ns4:Description>a description comment</ns4:Description>
<ns4:Reference>001</ns4:Reference>
</ns4:ReportingData>
<ns5:ApplicationConfigurationData xsi:nil="true" xmlns:ns5="http://schemas.abcommerce.com/CWS/v2.0/Transactions/Bankcard"/>
<ns6:TenderData xmlns:ns6="http://schemas.abcommerce.com/CWS/v2.0/Transactions/Bankcard">
<ns7:PaymentAccountDataToken xsi:nil="true" xmlns:ns7="http://schemas.abcommerce.com/CWS/v2.0/Transactions"/>
<ns8:SecurePaymentAccountData xsi:nil="true" xmlns:ns8="http://schemas.abcommerce.com/CWS/v2.0/Transactions"/>
<ns9:EncryptionKeyId xsi:nil="true" xmlns:ns9="http://schemas.abcommerce.com/CWS/v2.0/Transactions"/>
<ns10:SwipeStatus xsi:nil="true" xmlns:ns10="http://schemas.abcommerce.com/CWS/v2.0/Transactions"/>
<ns6:CardData>
<ns6:CardType>Visa</ns6:CardType>
<ns6:CardholderName xsi:nil="true"/>
<ns6:PAN>4111111111111111</ns6:PAN>
<ns6:Expire>1210</ns6:Expire>
<ns6:Track1Data xsi:nil="true"/>
<ns6:Track2Data xsi:nil="true"/>
</ns6:CardData>
<ns6:CardSecurityData>
<ns6:AVSData>
<ns6:CardholderName xsi:nil="true"/>
<ns6:Street> 4 corporate sq</ns6:Street>
<ns6:City xsi:nil="true"/>
<ns6:StateProvince xsi:nil="true"/>
<ns6:PostalCode>303292102</ns6:PostalCode>
<ns6:Phone xsi:nil="true"/>
<ns6:Email xsi:nil="true"/>
</ns6:AVSData>
<ns6:CVDataProvided>Provided</ns6:CVDataProvided>
<ns6:CVData>123</ns6:CVData>
<ns6:KeySerialNumber xsi:nil="true"/>
<ns6:PIN xsi:nil="true"/>
<ns6:IdentificationInformation xsi:nil="true"/>
</ns6:CardSecurityData>
<ns6:EcommerceSecurityData xsi:nil="true"/>
<ns6:EBTVoucherApprovalCode xsi:nil="true"/>
<ns6:EBTVoucherNumber xsi:nil="true"/>
</ns6:TenderData>
<ns11:TransactionData xsi:type="ns1:BankcardTransactionDataPro" xmlns:ns11="http://schemas.ipcommerce.com/CWS/v2.0/Transactions/Bankcard">
<ns12:Amount xmlns:ns12="http://schemas.abcommerce.com/CWS/v2.0/Transactions">211.00</ns12:Amount>
<ns13:CurrencyCode xmlns:ns13="http://schemas.abcommerce.com/CWS/v2.0/Transactions">USD</ns13:CurrencyCode>
<ns14:TransactionDateTime xmlns:ns14="http://schemas.abcommerce.com/CWS/v2.0/Transactions"></ns14:TransactionDateTime>
<ns15:CampaignId xsi:nil="true" xmlns:ns15="http://schemas.abcommerce.com/CWS/v2.0/Transactions"/>
<ns16:Reference xmlns:ns16="http://schemas.abcommerce.com/CWS/v2.0/Transactions">001</ns16:Reference>
<ns11:AlternativeMerchantData xsi:nil="true"/>
<ns11:ApprovalCode xsi:nil="true"/>
<ns11:EmployeeId>001</ns11:EmployeeId>
<ns11:EntryMode>Keyed</ns11:EntryMode>
<ns11:IndustryType>MOTO</ns11:IndustryType>
<ns11:InternetTransactionData xsi:nil="true"/>
<ns11:InvoiceNumber xsi:nil="true"/>
<ns11:OrderNumber>123654</ns11:OrderNumber>
<ns11:IsPartialShipment>false</ns11:IsPartialShipment>
<ns11:SignatureCaptured>false</ns11:SignatureCaptured>
<ns11:TerminalId xsi:nil="true"/>
<ns11:LaneId xsi:nil="true"/>
<ns11:BatchAssignment xsi:nil="true"/>
<ns11:ScoreThreshold xsi:nil="true"/>
<ns1:Level2Data>
<ns11:CommodityCode xsi:nil="true"/>
<ns11:CompanyName xsi:nil="true"/>
<ns11:CustomerCode xsi:nil="true"/>
<ns11:DestinationPostal xsi:nil="true"/>
<ns11:Description xsi:nil="true"/>
<ns11:OrderNumber xsi:nil="true"/>
<ns11:RequesterName xsi:nil="true"/>
<ns11:ShipFromPostalCode xsi:nil="true"/>
<ns11:ShipmentId xsi:nil="true"/>
<ns11:TaxExempt xsi:nil="true"/>
<ns11:Tax xsi:nil="true"/>
</ns1:Level2Data>
<ns1:LineItemDetails xsi:nil="true"/>
<ns1:PINlessDebitData>
<ns17:BillPayServiceData xmlns:ns17="http://schemas.abcommerce.com/CWS/v2.0/Transactions">
<ns17:CompanyName>ABC LLC.</ns17:CompanyName>
<ns17:CompanyAddress>
<ns17:Street1>123 main st</ns17:Street1>
<ns17:Street2 xsi:nil="true"/>
<ns17:City>XMO</ns17:City>
<ns17:StateProvince>CO</ns17:StateProvince>
<ns17:PostalCode>90456</ns17:PostalCode>
<ns17:CountryCode>USA</ns17:CountryCode>
</ns17:CompanyAddress>
</ns17:BillPayServiceData>
<ns18:PayeeData xmlns:ns18="http://schemas.abcommerce.com/CWS/v2.0/Transactions">
<ns18:CompanyName>MDK</ns18:CompanyName>
<ns18:Phone>1235</ns18:Phone>
<ns18:AccountNumber>123456789</ns18:AccountNumber>
</ns18:PayeeData>
</ns1:PINlessDebitData>
<ns1:IIASData xsi:nil="true"/>
</ns11:TransactionData>
<ns1:InterchangeData xsi:nil="true"/>
</transaction>
<applicationProfileId>${ApplicationProfileId}</applicationProfileId>
<merchantProfileId>${MerchantProfileId}</merchantProfileId>
<workflowId>${ServiceID}</workflowId>
</AuthorizeAndCapture>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>  

Recurring Payments

Recurring payments are transactions for which a cardholder provides written permission to a merchant to periodically charge his/her account number for recurring goods or services. These may include payment of charges such as insurance premiums, subscriptions, membership fees, tuition, or utility charges. Address Verification must be performed with the initial authorization request, but is not required on subsequent recurring transactions that contain the recurring transaction indicator. Address Verification is required to be obtained on a yearly basis.Visa requires that the initial authorization and settlement transaction must indicate how the merchant obtained the card holder number (card-present, mail/telephone order, internet, etc). The initial authorization and settlement request should not contain the recurring transaction indicator (value of the CWS BillPayment enumeration); only subsequent transactions will contain the recurring transaction indicator.MasterCard and American Express require that both the initial and subsequent authorization and settlement transactions contain the recurring transaction indicator as well as how the card information was obtained from the cardholder (face-to-face, internet, mail order, etc).When supporting recurring payment transactions in CWS:

  • BankcardTransactionPro.InterchangeData.BillPayment must be set to “Recurring”.
  • BankcardTransactionPro.InterchangeData.CurrentInstallmentNumber must be set to “1” for the first transaction of a recurring payment series. Subsequent payments must be set to any value greater than 1.
  • BankcardTransactionPro.InterchangeData.ExistingDebt must be set to “NotExistingDebt” unless the customer participates in the Visa Debt Repayment Program. Flagging a Visa transaction as existing debt will result in declines when not used properly.
  • BankcardTransaction.BankcardTransactionData.CustomerPresent must be set to “BillPayment”.
  • BankcardTransaction.BankcardTransactionData.OrderNumber cannot be blank or all zeroes.

The recurring transaction indicator must be present in the authorization and settlement message formats. An additional response “Merchant Advice Code Indicator” may be returned to assist the merchant with the reason for declining a recurring transaction when the appropriate recurring indicators are present in the authorization request message. To receive this message, set BankcardTransactionDataDefaults.RequestAdvice to “Capable”. If provided, the response message will be returned in BankcardTransactionResponse.AdviceResponse.  Soft Descriptors

  • The purpose of soft descriptor data is to override information that is stored for the merchant on First Data‘s Merchant Master. Merchant Name, City, and State must be completely entered, otherwise the legal name in First Data‘s Merchant Master will be used. It is recommended for American Express and PIN Debit transactions that the Street Address also be provided.
  • The following fields must be submitted in BankcardTransaction.BankcardTransactionData.AlternativeMerchantData:

 

  • Name (AN 30)
    Note: Third-party aggregators processing American Express cards should provide unique processing identifiers in this field. This is a unique, merchant-assigned, 16-byte (max), alphanumeric seller/vendor code in the format "S#nnnnnnnnnnnnnnn".
  • The following fields must be submitted in BankcardTransaction.BankcardTransactionData.AlternativeMerchantData.Address:
    • Street1 (AN 25)
    • City (AN 20)
    • StateProvince (AN 2)
    • PostalCode (AN 9)
    • CountryCode (AN 3)
    Important! The AlternativeMerchantData values above must be less than or equal to the specified alpha numeric (AN) character limits to avoid transaction failures.

CWS API Data Elements: BankcardTransaction, BankcardTransactionData, AlternativeMerchantData, AddressInfo   Transaction Amount TolerancesIn order to qualify for the best interchange rates and to further protect the merchant from chargebacks, authorization and settlement amounts for transactions must be within certain tolerance ranges. These tolerance ranges vary by card type and payment industry.Note: Non-bankcard issuers (American Express, Discover, JCB, and private label issuers) do not support transaction tolerance requirements.  Verified-by-Visa (VbV)Verified-by-Visa (VbV) and MasterCard SecureCode (MCSC) are solutions designed to authenticate cardholders when making purchases online. Both of these programs require a merchant’s website (or cardholder) to have additional software that will allow interaction with the cardholder’s issuing bank at the time that the purchase is being made. This interaction will allow the cardholder to be authenticated at the time of the purchase. Once authenticated, the issuer will provide authentication data that must be passed to the host during the credit authorization process. The issuer will have an opportunity to validate the authentication data and respond accordingly.VbV was created to add a new level of security to Internet transactions by verifying a cardholder’s ownership of an account, in real time, during an online payment transaction. VbV gives Visa card issuers the ability to confirm a cardholder’s identity using a variety of authentication methods, including passwords, chip cards, and digital certificates. Providing merchants with real time authentication results during the checkout process creates a safer and more cost-effective eCommerce solution for merchants and consumers. VbV is based on the 3-D Secure Protocol, which uses Secure Sockets Layer (SSL) encryption to collect and protect payment card information transmitted via the Internet.Visa International and Visa U.S.A. operating regulations shift fraud chargeback liability from merchant to Issuer when a merchant submits proof that they authenticated or attempted to authenticate the cardholder in a VbV transaction.The Merchant must not store and submit the Cardholder Authentication Verification Value (CAVV) with any subsequent transaction. Cardholders may dispute that they did not authorize the recurring payments charged to their account. As a result, subsequent recurring payments are subject to chargeback if disputed by the cardholder.For more detailed information regarding these programs, contact your NAB Velocity Sales Engineer.When supporting VbV transactions in CWS:

  • If a token is obtained:
    • BankcardTransaction.BankcardTenderData.EcommerceSecurityData.TokenData is required and contains the token provided by the service.
    • BankcardTransaction.BankcardTenderData.EcommerceSecurityData.TokenIndicator is required and must be set to “VPAS”.
    • BankcardTransaction.BankcardTenderData.EcommerceSecurityData.XID is optional and may contain the Visa XID value.
  • If VbV is supported but the token could not be obtained:
    • BankcardTransaction.BankcardTenderData.EcommerceSecurityData.TokenData will not be populated.
    • BankcardTransaction.BankcardTenderData.EcommerceSecurityData.TokenIndicator is required and must be set to “AttemptedCardUnsupported” or “AttemptedServiceUnavailable”.

American Express

  • Industry-specific data must be present in all transactions.

Discover

  • Industry-specific data must be present in all transactions.

MasterCard

  • The transaction must be settled within 48 hours.
  • Industry-specific data must be present in all transactions.
  • Fast Food and Beauty Shop transactions must be within 25% of the original authorization amount. All other Retail transactions must be within 10% of the original authorization amount.
  • Cardholder signature is required for card-present transactions.

Visa

  • The transaction must be settled within 48 hours.
  • Industry-specific data must be present in all transactions.
  • The settlement amount must match the authorized amount.
  • If the transaction must be manually keyed, AVS must be requested. A match of the zip code is required.
  • Cardholder signature is required for card-present transactions.

American Express

  • The transaction should be settled within 24 hours after the shipment.
  • Industry-specific data must be present in all transactions.

Discover

  • The transaction should be settled within 24 hours after the shipment.
  • Industry-specific data must be present in all transactions.

MasterCard

  • The transaction must be settled within 24 hours.
  • Industry-Specific Data must be present in all transactions.
  • The settled transaction amount must be within tolerance of the authorized amount. The initial authorization/sale must be submitted for the actual transaction amount. It must not be altered to include an additional percentage that accounts for a tip being added before settlement.
  • Cardholder signature is required for card-present transactions.

Visa

  • The transaction must be settled within 48 hours.
  • Industry-specific data must be present in all transactions.
  • The settled transaction amount must be within tolerance of the authorized amount. The initial authorization/sale must be submitted for the actual transaction amount. It must not be altered to include an additional percentage that accounts for a tip being added before settlement.
  • If the transaction must be manually keyed, AVS must be requested. A match of the zip code is required.
  • Cardholder signature is required for card-present transactions.

American Express

  • The transaction should be settled within 24 hours after the shipment.
  • Industry-specific data must be present in all transactions.
  • The transaction date should match the shipment date.

Discover

  • The transaction should be settled within 24 hours after the shipment.
  • Industry-specific data must be present in all transactions.
  • The transaction amount should match the final authorized amount. One partial reversal is allowed to bring the authorization amount within tolerance.
  • The transaction date must match the shipment date.

MasterCard

  • The transaction must be settled within 48 hours.
  • Industry-specific data must be present in all transactions.
  • The transaction amount should match the final authorized amount. One partial reversal is allowed to bring the authorization amount within tolerance.

Visa

  • The transaction must be settled within 48 hours.
  • Industry-specific data must be present in all transactions.
  • The transaction amount must match the final authorized amount. Amount tolerance between authorization and clearing is 0%. One partial reversal is allowed to bring the authorization amount within tolerance.
  • The transaction date must match the ship date and must be no later than 7 days after the authorization date.
  • The original approval number must be submitted in settlement.
  • Address Verification Service (AVS) - Single purchase transactions must request AVS. A match is not required.

American Express

  • The transaction should be settled within 24 hours after the shipment.
  • Industry-specific data must be present in all transactions.
  • The transaction date should match the shipment date.

Discover

  • The transaction should be settled within 24 hours after the shipment.
  • Industry-specific data must be present in all transactions.
  • The transaction amount should match the final authorized amount. One partial reversal is allowed to bring the authorization amount within tolerance.
  • The transaction date must match the shipment date.

MasterCard

  • The transaction must be settled within 48 hours.
  • Industry-specific data must be present in all transactions.
  • The transaction amount should match the final authorized amount. One partial reversal is allowed to bring the authorization amount within tolerance.
  • Recurring Billing transactions require the recurring billing flag.

Visa

  • The transaction must be settled within 48 hours.
  • Industry-specific data must be present in all transactions.
  • The transaction amount must match the final authorized amount. Amount tolerance between authorization and clearing is 0%. One partial reversal is allowed to bring the authorization amount within tolerance.
  • The transaction date must match the ship date and must be no later than 7 days after the authorization date.
  • The original approval number must be submitted in settlement.
  • Address Verification Service (AVS) - Single purchase transactions must request AVS. A match is not required.
  • Recurring billing transactions must request AVS on the initial authorization. AVS is optional on all subsequent authorizations.

American Express Card Identifier (CID)4-digit number on the front of the card above and right of the account number.Discover Card Identifier (CID)3-digit number on the back of the card next to the account number on the signature panel.MasterCard Enhanced Card Verification Code (CVC2)3-digit number on the back of the card next to the account number on the signature panel.Visa Enhanced Card Verification Value (CVV2)3-digit number on the back of the card next to the account number on the signature panel.American ExpressAmerican Express does not have the same strict tolerance rules as other payment brands. American Express does not provide support for incremental authorizations or partial reversals.DiscoverDiscover does not have the same strict tolerance rules as other payment brands. Discover does not provide support for incremental authorizations, but does provide support for partial reversals.MasterCard

MasterCard does not have the same strict tolerance rules as Visa. MasterCard does not provide support for incremental authorizations, but does provide support for partial reversals.

  • Restaurant, fast food, bars, nightclubs: Exempt from tolerance checking.
  • Beauty shops: +/- 25%
  • All other industries: +/- 10%

Visa

Visa supports very strict tolerance levels; however, they do provide support for incremental and partial reversal transactions so that the authorized and settled amounts can come within the allotted tolerance.

  • Lodging: +/- 15% - Incremental and partial reversal authorizations allowed.
  • Auto Rental: +/- 15% - Incremental and partial reversal authorizations allowed.
  • Retail: None - No incremental or partial reversal authorizations allowed.
  • Restaurant: +/- 20% - No incremental or partial reversal authorizations allowed.
  • MOTO: None – Partial reversal authorizations allowed.
  • eCommerce: None - Partial reversal authorizations allowed.
  • Petroleum: None - No incremental or partial reversal authorizations allowed.

Comments