dsiEMVUS Batch Functions

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

End-of-Day Batch Closing and Settlement

 

In addition to managing payment modules, many POS systems also manage the end-of-day batch closing and settlement procedures. dsiEMVUS offers  a variety of capture and close methods to meet the needs of today’s complex payment systems.

 

 

Time-Initiated Batch Close 

 

Time-initiated batch close is an auto-settle function whereby all captured transactions are settled in one batch at 4:00 AM Eastern Standard Time (EST). Other close times may be available based on sponsoring bank arrangements, end-of-day closing time and funding times needed.

 

Recommended for: all general retail, quick serve/fast food, and eCommerce. These verticals do not typically process tips or need to modify the original authorization amount.

 

Time-initiated avoids the common issue of a merchant forgetting to close their batch, or having problems matching up their totals and number of transactions.

 

The developer does not need to write code to support a BatchClose transaction.

The 4:00 AM EST may not be optimal for some West Coast, Hawaiian or Alaskan merchants.

 

 

Merchant-Initiated Batch Close

 

Merchant-initiated means the batch is settled by using a local command. This can be either a local, merchant-facing BatchClose command from the payment application, or an auto-generated BatchClose from the payment server that initiates the settlement process.

 

Recommended for: table service restaurants, nightclubs and bars where tip adjustments commonly occur, and for merchants who need local control over their batch closing time.

 

Merchants must close their batch within 24 hours of the original authorization or they will face downgrades (higher transaction rates). This is because authorization codes increasingly lose their interchange authenticity over time and inherently carry higher risk. If a batch remains open too long, there is built-in protection that stops accepting additional capture transactions and returns the message, “MUST BALANCE NOW” or “USE DUP THEN BAL”.

 

The maximum size for a merchant-initiated batch is approximately 4500 transactions. It is important to avoid hitting this threshold. If it is reached, the merchant will receive a MUST BALANCE NOW message, and will have no recourse for adding gratuities or adjusting any transactions. Processing will be temporarily interrupted until the batch is successfully closed. Businesses that reach this threshold often have multiple locations routing transactions to a single Merchant ID. An easy way to avoid reaching the threshold and risk being unable to process is to simply implement different Merchant ID’s at each location.

 

The merchant-initiated batch close uses a two-step set of Admin transactions requests: BatchSummary and BatchClose.

BatchSummary provides merchants with a list of batch item counts and totals stored on the MercuryPay servers, which they can compare to their local counts and totals to make sure they match before closing the batch. Once this is done, merchants proceed to close the batch.

 

 

BatchSummary 

 

Request

 

<?xml version="1.0"?> 
<TStream> 
<Admin> 
<MerchantID>755847002</MerchantID> 
       <TranCode>BatchSummary</TranCode> 
       <Memo>Demo POS</Memo> 
     </Admin> 
</TStream> 

 

Response

 

<?xml version="1.0"?>
<RStream>
  <CmdResponse>
    <ResponseOrigin>Processor</ResponseOrigin>
    <DSIXReturnCode>000000</DSIXReturnCode>
    <CmdStatus>Success</CmdStatus>
    <TextResponse>OK</TextResponse>
    <UserTraceData></UserTraceData>
  </CmdResponse>
  <BatchSummary>
    <MerchantID>755847002</MerchantID>
    <BatchNo>1225</BatchNo>
    <BatchItemCount>18</BatchItemCount>
    <NetBatchTotal>16.79</NetBatchTotal>
    <CreditPurchaseCount>6</CreditPurchaseCount>
    <CreditPurchaseAmount>42.25</CreditPurchaseAmount>
    <CreditReturnCount>5</CreditReturnCount>
    <CreditReturnAmount>31.54</CreditReturnAmount>
    <DebitPurchaseCount>5</DebitPurchaseCount>
    <DebitPurchaseAmount>10.17</DebitPurchaseAmount>
    <DebitReturnCount>2</DebitReturnCount>
    <DebitReturnAmount>4.09</DebitReturnAmount>
  </BatchSummary>
</RStream>

 

 

BatchClose

 

Request

 

<?xml version="1.0"?>
<TStream>
<Admin>
   <MerchantID>755847002</MerchantID>
   <TranCode>BatchClose</TranCode>
   <BatchNo>1225</BatchNo>
   <BatchItemCount>18</BatchItemCount>
   <NetBatchTotal>16.79</NetBatchTotal>
   <CreditPurchaseCount>6</CreditPurchaseCount>
   <CreditPurchaseAmount>42.25</CreditPurchaseAmount>
   <CreditReturnCount>5</CreditReturnCount>
   <CreditReturnAmount>31.54</CreditReturnAmount>
   <DebitPurchaseCount>5</DebitPurchaseCount>
   <DebitPurchaseAmount>10.17</DebitPurchaseAmount>
   <DebitReturnCount>2</DebitReturnCount>
   <DebitReturnAmount>4.09</DebitReturnAmount>
   <Memo>Demo POS</Memo>
</Admin>
</TStream>

 

Response

 

<?xml version="1.0"?>
<RStream>
<CmdResponse>
<ResponseOrigin>Processor</ResponseOrigin><DSIXReturnCode>000000</DSIXReturnCode><CmdStatus>Success</CmdStatus><TextResponse>OK TEST</TextResponse><UserTraceData></UserTraceData>
</CmdResponse>
<BatchClose>
<MerchantID>755847002</MerchantID><BatchNo>1225</BatchNo><BatchItemCount>18</BatchItemCount><NetBatchTotal>16.79</NetBatchTotal><CreditPurchaseCount>6</CreditPurchaseCount><CreditPurchaseAmount>42.25</CreditPurchaseAmount><CreditReturnCount>5</CreditReturnCount><CreditReturnAmount>31.54</CreditReturnAmount><DebitPurchaseCount>5</DebitPurchaseCount><DebitPurchaseAmount>10.17</DebitPurchaseAmount><DebitReturnCount>2</DebitReturnCount><DebitReturnAmount>4.09</DebitReturnAmount><ControlNo>033204606</ControlNo>
</BatchClose>
</RStream>

Attachments

    Outcomes