Batch Process - Are we doing the best process

[mozvat]

Do we need to have the defined below process better. What is our competition doing regarding batches?

Here is the below process with our current platform. I don't think the current prototype API does a batch clear...

End of Day Sequence in Batch Capture Environments:

1. POS sends a BatchClear command.
2. Send all the capture transactions, one right after the other.
3. Send a BatchSummary to verify the local number of transactions against the host number.
4. Send the BatchClose.
5. It is recommended to notify the merchant if the local and host totals did not match, but this should not prevent the BatchClose.
6. In the event there is a problem with the BatchClose, a BatchClear transaction should be again sent to the host (do not clear the batch locally or when debits are present) to void out all of the PreAuthCaptures that were sent to the host on the first attempt.
7. Start the BatchClose process from the beginning.

[esear]

Excellent - I've been thinking about this as well. It seems we have a chance to simplify this. In my (non-card processing) mind, it seems we need to support these actions:

1. submit a batch for closing /batch POST with the body of the POST containing all of the capture transactions in JSON which returns batchID
2. check on the status of a batch, which could include verifying the totals /batch GET with an ID

Alternatively, if we still wanted to receive all of the capture transactions individually we could

1. request the creation of a batch ID /batch POST with the totals in the body of the POST, responds with batchID
2. post individual transactions, with the batchID in the body of the POST /batch/transaction POST with capture transaction details in the body of the POST as well as the batchID to which it should be associated
3. finalize batch /batch PUT supplying the batchID
4. check status of the batch /batch GET supplying the batchID

[mozvat]

Comment via Dan Ourada

1. The whole conversation of batch processing is ugly. No one likes the way it is done today, merchants do not like it, developers do not like it, it’s difficult to explain to people how it works, etc. This is the perfect opportunity for Mercury to make it better. I’m not sure what the answer is, it would take some investigation from your product team but this is a fantastic area for innovation. There are many reasons why it’s a pain: a. Time initiated – if it’s time initiated that jacks with merchant funding unless MPS can provide the merchant a way to select the exact time of the batch close. b. Batch reconciliation – I’m not sure why anyone ever does this, most people just send a batch summary and then close the batch so they can use merchant initiated batch close to work around the problem in (a). Maybe merchants did not trust the processor to contain their batch so they always wanted to reconcile prior to closing. What if instead MPS gave an easy BatchClose transaction that did all of the work for the merchant/POS developer? c. Tips/Adjusts/Voids/etc. – one reason to have a batch is so that before funds are captured all adjustments can be made so that card holders only see one transaction on their statement instead of 10. Typically one authorization would be sent to the processor and then many “adjustments/voids” could happen locally at the POS, then at the end of the day everything can be resolved via the “terminal” based batch close. One problem could have been the amount of time it takes to send a transaction and people did not want to wait 30 seconds to add a tip to a transaction. With IP processing this goes away so maybe it’s not even a problem any longer? In which case (a) and (b) solve the problems.