dsiPDCX FSA Examples

Document created by matthew.milner on May 11, 2016Last modified by Chris Jennings on Jun 1, 2016
Version 2Show Document
  • View in full screen mode

FSA Transaction XML Request and Responses

This section provides example XML request and response data for ProcessTransaction commands passed to the dsiPDCX for FSA processing. Only REQUIRED data elements are shown in the examples. For a complete list of required and optional data elements refer to the XML request and Response Table

 

A Flexible Spending Account (FSA) is a tax-favored program offered by employers that allows their employees to pay for eligible out-of-pocket health care and dependent care expenses with pre-tax dollars. FSA cards are annually loaded, “stored value” cards that are only good for their available balance.

 

MercuryPay supports two necessary components of the FSA transaction approval cycle:

  • FSA transactions
  • An FSA Card Lookup database used to identify valid FSA BIN ranges

 

In addition to the Vantiv Integrated Payments certification, developers will need to independently register with SIGIS, an organization responsible for promoting an industry standard to meet IRS requirements for operating an Inventory Information Approval System (IIAS). The IIAS database is used to determine which items qualify for FSA at the point of purchase. Vantiv Integrated Payments recommends that developers interested in supporting FSA begin the SIGIS registration process immediately upon starting their FSA integration.

 

Note 

  • FSA Certification and SIGIS registration are not required for merchant environments that perform medical services and fall into merchant category codes (MCC/SIC codes) within the 8000 range.
  • FSA certification and SIGIS qualification is required for merchant environments that fall under the SIGIS 90% rule or who use a mixture of IIAS FSA eligible and non-eligible goods.

 

Required FSA Transactions 

There are three FSA specific transactions required for certification:

 

1. CardLookup.  Used to determine that the card is an FSA card. Only legitimate FSA cards can be used for eligible FSA transactions. To determine this, developers must first send a CardLookup that returns a Card Usage of “FSA.” “DEBIT” and “OTHER” are the alternate usage responses.  If “FSA” is not returned in the response, the transaction may still be completed as a standard credit or debit sale.

 

2. FSASale.  This is the standard authorization request when using an FSA card. FSASale includes support for partial payments based on the available balance on the card. If the purchase amount exceeds the available balance, the card issuer will return PARTIAL AP in the response indicating that the transaction was only partially approved. The POS system should include “balance due” logic. More details are provided below.

 

The FSA Prescription subfield must be included in the Amount field of all FSASale transactions. The Purchase amount includes the prescription amount and the FSAPrescription breaks out the prescription amount separately:

 

<Amount> 
<Purchase>6.00</Purchase> 
<FSAPrescription>4.00</FSAPrescription> 
</Amount> 

 

3. ReverseFSASale.  Reverses the sale and returns the funds to the cardholder’s available balance  within 2-72 hours.  Always send AcctNo and ExpDate in the Account field. If the ReverseFSASale fails, send a VoidSale. POS developers are required to include void functionality in case the ReverseFSASale fails or declines.

 

Card Lookup

Request

<?xml version="1.0"?> 
<TStream> 
  <Transaction> 
    <MerchantID>755847002</MerchantID> 
    <TranType>CardLookup</TranType>   
      <Track2>4005550000000480=12055025432198712345</Track2> 
    </Account> 
  </Transaction> 
</TStream> 

 

Response

<?xml version="1.0"?> 
<RStream> 
  <CmdResponse> 
    <ResponseOrigin>Server</ResponseOrigin> 
    <DSIXReturnCode>000000</DSIXReturnCode> 
    <CmdStatus>Approved</CmdStatus> 
    <TextResponse>SUCCESSFUL LOOKUP</TextResponse> 
    <UserTraceData></UserTraceData> 
  </CmdResponse> 
  <TranResponse> 
    <MerchantID>755847002</MerchantID> 
    <AcctNo>4005550000000480</AcctNo> 
    <ExpDate>0512</ExpDate> 
    <CardUsage>FSA</CardUsage>   
    <CardType>VISA</CardType> 
    <TranType>CardLookup</TranType> 
    <TranCode>CardLookup</TranCode> 
  </TranResponse> 
</RStream>  

 

FSASale with PARTIAL AP

Request

<?xml version="1.0"?> 
<TStream> 
<Transaction> 
<MerchantID>755847002</MerchantID> 
<LaneID>02</LaneID>  
<TranType>Credit</TranType> 
<TranCode>FSASale</TranCode>  
<InvoiceNo>11</InvoiceNo> 
<RefNo>11</RefNo> 
<Memo>Demo POS</Memo> 
<Account> 
<Track2>4005550000000480=12055025432198712345</Track2> 
</Account> 
<Amount> 
<Purchase>23.54</Purchase> 
<FSAPrescription>10.00</FSAPrescription>  
</Amount> 
</Transaction> 
</TStream> 

 

Response

<?xml version=”1.0”?> 
<RStream> 
 <CmdResponse> 
 <ResponseOrigin>Processor</ResponseOrigin> 
 <DSIXReturnCode>000000</DSIXReturnCode> 
 <CmdStatus>Approved</CmdStatus> 
 <TextResponse>PARTIAL AP</TextResponse> 
<UserTraceData></UserTraceData> 
 </CmdResponse> 
 <TranResponse> 
 <MerchantID>755847002</MerchantID> 
<AcctNo>4005550000000480</AcctNo> 
<ExpDate>0512</ExpDate> 
<CardType>VISA</CardType> 
<TranCode>FSASale</TranCode> 
<AuthCode>VI2354</AuthCode> 
 <CaptureStatus>Captured</CaptureStatus> 
<RefNo>0019</RefNo> 
 <InvoiceNo>11</InvoiceNo> 
<Memo>Demo POS</Memo> 
<Amount> 
<Purchase>23.54</Purchase>  
 <Authorize>20.00</Authorize>  
</Amount> <AcqRefData>aEb900700000555404cRBBCd5e10fMj101376090107235400k0057840C000000002354lA m000005</AcqRefData>  
  <ProcessData>|00|410100200000</ProcessData> 
 </TranResponse> 
 </RStream> 
3 people found this helpful

Attachments

    Outcomes