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>
Good News from Datacap! A new FSA path was released in dsiPDCX 1.45:
We’re releasing a new version of dsiPDCX today.
Version 1.45 adds support for an alternate format of an FSA Sale transaction. Rather than send an FSA Sale, the developer can send a Credit Sale transaction with a list of FSA BINs. If the card data collected by dsiPDX matches any of the FSA BINs, then the transaction is converted to an FSA Sale and sent to NETePay. If the card data does not match any of the FSA BINs, then the transaction is sent to NETePay as the original Credit Sale.
The dsiPDCX FSA Transactions Supplement document has been updated to reflect this additional way to perform an FSA Sale.
The install package for dsiPDCX 1.45 is available on the software download site.
Alternatively, in an EMV configuration, check out Processing FSA transactions with dsiEMVUS