Sorry to get your hopes up but I am reliably informed that you cannot do this. And the reason? “PCI Compliance”.
Let me take a few steps back and explain. When you use the EFT module (which is standard in the UK version) to automatically populate a batch with gifts there is a field called Rejection Code. I do not know the details of exactly how Blackbaud use this together with IATS and ICVerify but it is there. What is more you are able to populate it with your own rejection codes. When I was working with one organisation they did just that. They would send of their transmission file to BACS and enter the reason for a payment rejection into the rejection code field. When they then committed the batch any rows with a value in the rejection code field would cause and batch row exception and would give the rejection code as the reason. Those rows would then be added to a new exception batch for processing or discarding as seen fit. Sounds like a good system to me.
I am currently working on some banking procedures for a client from a country outside of Blackbaud’s core countries (US, Canada, UK, Australia, New Zealand, etc) where there is no banking process built into RE. They have a similar process. Create a transmission file for a batch of gifts, send it off to the clearing house and wait for any rejections. I had planned to use the API to populate the rejection code field in the batch so that those rows would cause an exception.
The first problem was that the rejection code is not part of a gift object. Instead I simply looped through the fields in the batch looking for the one with the name “Rejection Code”. Once I had found its position I could simply write to the tempRecord as below:
For Each batchField In batchFields If batchField.Fields(EBatchFieldFields.BatchField_fld_FieldName) = "Rejection code" Then rejectCodeField = batchField.Fields(EBatchFieldFields.BatchField_fld_Sequence) Exit For End If Next batchField tempRecord.Fields(rejectCodeField) = rejectCode
This worked fine. The value was in the tempRecord (I queried it in the immediate window and the value was there). I saved the tempRecords collection, saved the batch and went to look in the batch to see if it was there. There was no sign of the value. Just empty.
When I asked Blackbaud support for an example of how to do this they were not able to do so either. I said that it must be possible as the IATS and ICVerify code writes to these fields. Could you not simply let me see the code that they use to write to this field. So I perhaps should not have asked to see the code but rather be told how they do it. However the response I received was that:
“We do not provide code for IATS, BBPS, or ICVerify as this would violate PCI compliance.”
After some explanation I was told:
“It is not populating a rejection code field that would be a violation of PCI compliance. However, revealing source code from IATS or ICVerify would be a violation of compliance.”
I really do not understand how giving me the technique that was used is in breach of PCI compliance. What seems more likely is that the solution uses “the other API” i.e. the dlls that RE uses itself and not the one that is exposed to users of the RE:API module. There are several circumstances when you have to use the RE dlls when working with batch (as has been highlighted earlier in this blog). What is interesting is that if you search the object browser for “reject” you get the following fields:
Public Const GIFTREJECTIONCODE As Blackbaud.PIA.RE7.BatchData.EBATCH_GiftSpecialFields = 202
Public Const BatchGift_Fld_RejectionCode As Blackbaud.PIA.RE7.BatchData.EBatchGiftFields = 64
The question is how are they used with the other batch objects to get this solution to work. If anyone know please do leave a comment!