CORE-POS / IS4C

Cooperative Operational Retail Environment
http://www.core-pos.com
GNU General Public License v2.0
63 stars 44 forks source link

Gift Card Processing configuration help #1209

Open joelbrock opened 9 months ago

joelbrock commented 9 months ago

After swiping Giftcard: ERROR MESSAGE: MerchantID Not Found

Trying to configure integrated Gift Cards using the inhouse gift cards from FirstData. The gift processor is Valuelink. In the only other successful integration like this i've done we used the Buypass Merchant ID for both EMV and Gift Card MIDs. However in this current case, the Buypass MID is not used for gift, and we have a different North MID for Gift Cards, 11 digits long.

I went to Install > Plugins > Paycards to update the Gift Terminal ID value there. Formatted like ::00000000

However, changes to this field dont seem to affect what is getting used as an MID on Giftcard transactions. log.xml shows the EMVTerminalID value no matter what.

So. If you followed all of that:

How can I get Paycard plugin to send different MID for Gift transactions using available tools? Is there an ini.json value i could define? Other?

Thanks!

11/14/2023 4:16:09 PM (send pdc): <?xml version="1.0"?>            
<TStream>            
<Transaction>            
  <MerchantID>00123456</MerchantID>
  <TerminalID>00000001</TerminalID>
            <OperatorID>52</OperatorID>
            <LaneID>1</LaneID>
            <InvoiceNo>1010101010101010101</InvoiceNo>
            <RefNo>10101010101010101010101</RefNo>
            <Memo>CORE POS 1.0.0</Memo>
            <RecordNo>RecordNumberRequested</RecordNo>
            <Frequency>OneTime</Frequency>
            <Amount>
                <Purchase>1.00</Purchase>
            </Amount>
    <MaxTransactions>50</MaxTransactions>
    <OfflineTransactionPurchaseLimit>500</OfflineTransactionPurchaseLimit>
    <ResponseTimeout>24</ResponseTimeout>
    <TranCode>NoNSFSale</TranCode>
            <SecureDevice>INGENICOLANE8000_RAPIDCONNECT_E2E</SecureDevice>
            <ComPort>9</ComPort>
            <CollectData>CardholderName</CollectData>
            <Account>
                <AcctNo>SecureDevice</AcctNo>
            </Account>
            <TranType>PrePaid</TranType>
<IpPort>9100</IpPort>
<IpAddress>74.120.158.37</IpAddress>            
</Transaction>            
</TStream>
11/14/2023 4:16:09 PM (recv pdc): <?xml version="1.0"?>
<RStream>
<CmdResponse>
                        <ResponseOrigin>Processor</ResponseOrigin>
                        <DSIXReturnCode>000000</DSIXReturnCode>
                        <CmdStatus>Declined</CmdStatus>
                        <TextResponse>MerchantID Not Found</TextResponse>
                        <UserTraceData></UserTraceData>
</CmdResponse>
<TranResponse>
                        <TranType>PrePaid</TranType>
                        <TranCode>NoNSFSale</TranCode>
                        <AcctNo>10101010101010101010101010101010101</AcctNo>
                        <InvoiceNo>1010101010101010</InvoiceNo>
                        <MerchantID>00123456</MerchantID>
                        <OperatorID>52</OperatorID>
                        <CardholderName>SUPERVALU/VALUELINK</CardholderName>
</TranResponse>
</RStream>
gohanman commented 9 months ago

You'll have to change this function to be aware of the gift terminal ID https://github.com/CORE-POS/IS4C/blob/master/pos/is4c-nf/plugins/Paycards/MercuryDC.php#L382

Most concise option would be to adjust $termID inside this conditional https://github.com/CORE-POS/IS4C/blob/master/pos/is4c-nf/plugins/Paycards/MercuryDC.php#L415

It might be more readable to separate it out though into something like this:

if ($tranType == 'PrePaid' && strlen($this->conf->get('MercuryGiftID')) > 0) {
    $termID = $this->conf->get('MercuryGiftID');
}
joelbrock commented 9 months ago

Thanks! I tried a couple variations on this approach. Including a discrete conditional statement. A nested conditional, and then just no conditional at all. Interesting results:

I got a NEW error message: "No Usable Track2 Found in Message."

However, the MID is unchanged, regardless of what I put into the GiftTerminalID field. but also the block is missing, the PrePay tranType is not set?:

11/15/2023 3:06:19 PM (send pdc): <?xml version="1.0"?>            
<TStream>            
<Transaction>            
<MerchantID>00123456</MerchantID>            
                        <TerminalID>00000001</TerminalID>
            <OperatorID>1</OperatorID>
            <LaneID>2</LaneID>
            <InvoiceNo>111000000000000</InvoiceNo>
            <RefNo>111000000000000</RefNo>
            <Memo>CORE POS 1.0.0</Memo>
            <RecordNo>RecordNumberRequested</RecordNo>
            <Frequency>OneTime</Frequency>
            <Amount>
                <Purchase>0.01</Purchase>
                        </Amount>
                        <MaxTransactions>50</MaxTransactions><OfflineTransactionPurchaseLimit>500</OfflineTransactionPurchaseLimit><ResponseTimeout>24</ResponseTimeout><TranCode>NoNSFSale</TranCode>            <SecureDevice>INGENICOLANE8000_RAPIDCONNECT_E2E</SecureDevice>            <ComPort>9</ComPort>            <CollectData>CardholderName</CollectData>            <Account>                <AcctNo>SecureDevice</AcctNo>            </Account>            <TranType>PrePaid</TranType><IpPort>9100</IpPort><IpAddress>74.120.158.37</IpAddress>            
</Transaction>
</TStream>
11/15/2023 3:06:19 PM (recv pdc): <?xml version="1.0"?>
<RStream>
<CmdResponse>
<ResponseOrigin>Client</ResponseOrigin>
<DSIXReturnCode>003394</DSIXReturnCode>
<CmdStatus>Error</CmdStatus>
<TextResponse>No Usable Track2 Found in Message.</TextResponse>
<UserTraceData></UserTraceData>
</CmdResponse>
</RStream>
gohanman commented 9 months ago

That does have <TranType>PrePaid</TranType>.

No usable track 2 means a bad magstripe read and ResponseOrigin client means it didn't submit anything to the processor. Presumably on a good swipe the processor response would still complain about the MID.

jamesTSCoop commented 5 months ago

Hi, I've finally picked this issue up from Joel, and have moved it forward some. Per the changes suggested above to prepareDataCapBalance(), I didn't see the gift card merchant ID in the xml logs, so I dug deeper. I hypothesised that pDCB() might only be called for a balance inquiry, and I saw the need to adjust the code slightly to handle merchantID strings that end in "::" as both the normal and gift merchant IDs do in this case. I also thought I saw a code path through prepareDataCapGift () based on the xml log showing the g1.mercurypay.com IP address despite having the non-gift merchant ID. That path would not have been affected by the change in prepareDataCapBalance(), so I went to replicate the change there only to find pDCG() was using beginXmlRequest() to set up the values. bXR() is pulled in from MercuryE2E.php, so I adjusted that method to note if a gift card was in use and use the gift merchant ID instead of the normal one.

That brings me to my first question, is it safe in this instance to modify MercuryE2E.php or should I dup beginXmlRequest() in MercuryDC.php?

Secondly, both the changes took effect, see below, the first, InvoiceNo ...9006 is the balance inquiry with TranCode Balance and the 5..5 gift Merchant ID, and the third, InvoiceNo ...9008 which was supposed to be a gift card charge, TrandCode Issue, also has the 5..5 gift Merchante ID. However, between the two there was a third XML (send pdc), InvoiceNo ...9007, also with a TranCode Issue and the g1.mercurypay.com IP address, but with the 004..2 non-gift merchant ID.

So my second question is, it appears there's a third path that's engaged somehow, perhaps one of prepareDataCap{Auth,Void,Wic}()?

And my third question is, the balance inquiry and second TranCode:Issue should have gone through but both were declined <TextResponse>MerchantID Not Found</TextResponse>. I've confirmed the 5..5 gift MerchantID with MercuryPay's original email, but I note that our XML is sending to MercuryPay with the MerchantID set, but with a TerminalID of 00000001 not the TerminalID indicated in MercuryPay's email. I have a question out to MercuryPay if the TerminalID is necessary or not, but my question here is, if it is necessary, how do I inject it? The MercuryDC/E2E.php code leaves the XML as <TerminalID>{{TerminalID}}</TerminalID> and I presume that it is ProcessPDC() in SPH_Datacap_Gen2.cs that is expanding it, but I don't have a clue how to see that this.terminalID is set accordingly in ProcessPDC().

Any help much appreciated!

2/29/2024 2:40:07 PM (send pdc):  <?xml version="1.0" encoding="UTF-8"?>
<TStream>
   <Transaction>
      <MerchantID>54162560005</MerchantID>
      <TerminalID>00000001</TerminalID>
      <OperatorID>52</OperatorID>
      <LaneID>2</LaneID>
      <TranType>PrePaid</TranType>
      <TranCode>Balance</TranCode>
      <SecureDevice>INGENICOLANE8000_RAPIDCONNECT_E2E</SecureDevice>
      <ComPort>9</ComPort>
      <InvoiceNo>0229005202009006</InvoiceNo>
      <RefNo>0229005202009006</RefNo>
      <Memo>CORE POS 1.0.0 PDCX</Memo>
      <Account>
         <AcctNo>SecureDevice</AcctNo>
      </Account>
      <Amount>
         <Purchase>0.00</Purchase>
      </Amount>
      <IpPort>9100</IpPort>
      <IpAddress>74.120.158.37</IpAddress>
   </Transaction>
</TStream>

then

2/29/2024 2:40:33 PM (send pdc): <?xml version="1.0" encoding="UTF-8"?>
<TStream>
   <Transaction>
      <MerchantID>00423632</MerchantID>
      <TerminalID>00000001</TerminalID>
      <OperatorID>52</OperatorID>
      <LaneID>2</LaneID>
      <InvoiceNo>0229005202009007</InvoiceNo>
      <RefNo>0229005202009007</RefNo>
      <Memo>CORE POS 1.0.0</Memo>
      <RecordNo>RecordNumberRequested</RecordNo>
      <Frequency>OneTime</Frequency>
      <Amount>
         <Purchase>1.00</Purchase>
      </Amount>
      <MaxTransactions>50</MaxTransactions>
      <OfflineTransactionPurchaseLimit>500</OfflineTransactionPurchaseLimit>
      <ResponseTimeout>24</ResponseTimeout>
      <TranType>PrePaid</TranType>
      <TranCode>Issue</TranCode>
      <SecureDevice>INGENICOLANE8000_RAPIDCONNECT_E2E</SecureDevice>
      <ComPort>9</ComPort>
      <Account>
         <AcctNo>SecureDevice</AcctNo>
      </Account>
      <IpPort>9100</IpPort>
      <IpAddress>74.120.158.37</IpAddress>
   </Transaction>
</TStream>

then

2/29/2024 2:41:47 PM (send pdc): <?xml version="1.0" encoding="UTF-8"?>
<TStream>
   <Transaction>
      <MerchantID>54162560005</MerchantID>
      <TerminalID>00000001</TerminalID>
      <OperatorID>52</OperatorID>
      <LaneID>2</LaneID>
      <InvoiceNo>0229005202009008</InvoiceNo>
      <RefNo>0229005202009008</RefNo>
      <Memo>CORE POS 1.0.0</Memo>
      <RecordNo>RecordNumberRequested</RecordNo>
      <Frequency>OneTime</Frequency>
      <Amount>
         <Purchase>1.00</Purchase>
      </Amount>
      <MaxTransactions>50</MaxTransactions>
      <OfflineTransactionPurchaseLimit>500</OfflineTransactionPurchaseLimit>
      <ResponseTimeout>24</ResponseTimeout>
      <TranType>PrePaid</TranType>
      <TranCode>Issue</TranCode>
      <SecureDevice>INGENICOLANE8000_RAPIDCONNECT_E2E</SecureDevice>
      <ComPort>9</ComPort>
      <Account>
         <AcctNo>SecureDevice</AcctNo>
      </Account>
      <IpPort>9100</IpPort>
      <IpAddress>74.120.158.37</IpAddress>
   </Transaction>
</TStream>
gohanman commented 5 months ago

RE: modifying MercuryE2E.php: yes, that's fine. It wouldn't make much sense for anyone to use that module anymore since it doesn't and as far as I know can't ever support EMV.

RE: the 2nd question: no clue whatsoever, unfortunately. None of these operations should be automatically triggering any of the other operations.

RE: terminalID: that's coming in here: https://github.com/CORE-POS/IS4C/blob/master/pos/is4c-nf/scale-drivers/drivers/NewMagellan/SPH_Datacap_Gen2.cs#L495 and these options all get read from ini.json. There's not currently a way support multiple IDs. Probably the lowest friction way to at least test if it's the issue is to replace {{TerminalID}} yourself before posting the XML over to the C# process.

jamesTSCoop commented 5 months ago

Awesome, thanks!! If I track down that second send pdc path I might ask you about it but otherwise I think I'm good to go!

jamesTSCoop commented 2 months ago

Looping back around to this again, in conversation with the Gift card solution providers, they are saying that the gateway we are using for Gift transactions, "g1.mercurypay.com" is incorrect, and in order to tell us the correct gateway to use they need to know when/how CORE POS was certified for Gift on Fiserv. Ideas? Specifically they are trying to track down a TPP, Third Party Processor ID, and looking up Tech Support Coop isn't bringing anything up.

gohanman commented 2 months ago

I don't think that it ever was. Everything I did with Fiserv was via Datacap which presumably was itself certified.

jamesTSCoop commented 2 months ago

Thanks, I relayed a version of that. Now they are saying our Datacap cert doesn't include Gift, but they aren't sure and are asking if we think it did. Do you recall?

On Tue, 11 Jun 2024 at 11:09, Andy Theuninck @.***> wrote:

I don't think that it ever was. Everything I did with Fiserv was via Datacap which presumably was itself certified.

— Reply to this email directly, view it on GitHub https://github.com/CORE-POS/IS4C/issues/1209#issuecomment-2161007104, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKH5AAHJJBCHPDKXKBDNZ5DZG4HJJAVCNFSM6AAAAABJEPW2J2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRRGAYDOMJQGQ . You are receiving this because you commented.Message ID: @.***>

gohanman commented 2 months ago

No, or at least I never did gift card processing with Fiserv.