AnsweredAssumed Answered

VX805 / triPOS store and forward issue: unexpected response

Question asked by mark@vista on Jan 16, 2018
Latest reply on Mar 5, 2018 by mark@vista

Like • Show 0 Likes0
Comment • 7

Hi,

Our triPOS integration is proceeding apace, but we have just seen a previously unencountered issue with the triPOS service and the VeriFone VX805.

What is our environment?

Windows 10.

VeriFone VX805.

triPOS service version 5.14.

How do we reproduce the issue?

We are processing a payment for $21.00 using a SALE transaction.

EMV is enabled in the config file so the VX805 prompts "Insert or swipe card".

We are using the Vantiv Test Debit Card (9999 9998 0000 9901 PIN: 9901).

After swiping the card, the VX805 prompts for CREDIT or DEBIT selection.

Select DEBIT.

Disconnect from the network to cause store-and-forward to become active.

Confirm the amount (YES).

Enter the PIN (9901) and press the green key.

The display briefly shows "PROCESSING" then "CANCELLED" then returns to the idle message.

What is the issue?

After CANCELLED [dis]appears, the response from the triPOS service is empty.

This means we cannot load the XML we expected to extract the important values for our POS solution.

Currently this causes an error in our solution.

What do we expect?

triPOS to return a non-empty response such as CANCELLED or, perhaps, a response indicating DEBIT cards cannot be processed while offline.

How critical is this issue?

We will work around the issue, but a workaround does not resolve the underlying issue.

Thank you,

Mark Shipman

Payment Integration Developer

mark@vista Feb 1, 2018 1:07 PM

Correct Answer

Hi Daniel,

Thank you for the pointer about the different driver setting.

We were obviously not clear enough in our post.

We were not trying to solve the driver issue.

We are trying to show the inconsistency in triPOS's handling of exceptions.

In this example (incorrect driver setting), an exception occurs BUT triPOS still yields a valid XML document we can interrogate.

Contrast this with the debit card in a store-and-forward (network physically disconnected) situation. triPOS throws an exception And no XML document is yielded.

This situation then requires us to build an intimate knowledge of how triPOS works into our integration instead of always interrogating an XML document with a consistent structure.

Thanks, Mark Shipman

See the reply in context

No one else had this question

Outcomes

dmeeker Jan 26, 2018 9:48 AM

Hi Mark,

This is the expected behavior. triPOS won’t know that it needs to switch to offline mode until it tries to reach out to Express. All the card read/payment type validation process is done before reaching out to Express and that’s why when triPOS determines if the used payment type is valid for a transaction, it thinks it is in a regular, non-store mode so it prompts you the payment type options. When triPOS tries to reach to Express and determines that it can’t get to Express, it switches to store and forward mode and tries to store the transaction. At this time, it will try to store the transaction and would do some validations (check for debit, etc) that’s why you got an exception. If you try to send another sale transaction and use the same card, triPOS will behave differently because it now knows that it is in store and forward mode and will automatically process the card as Credit if it is credit capable.

Actions

mark@vista @ dmeeker on Jan 31, 2018 1:43 PM

Hi Daniel,

While we understand the flow you are describing and have no issue with it, triPOS will achieve a much better result if Vista (and other integrators) are not required to engineer our integration to take account of a special case like this.

Any other transaction seems to always yield a valid XML response.

To be consistent, triPOS should also return a valid XML response in this situation indicating the transaction was cancelled.

We can then process this in the same way as we do any other triPOS response.

Many thanks,

Mark Shipman

Actions

mark@vista @ dmeeker on Jan 31, 2018 4:49 PM

Hi Daniel,

Here is another example.

We are trying to connect a MX915 on lane 1.

Our SALE transaction receives this response:

<?xml version="1.0" encoding="utf-16"?>
<saleResponse xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://tripos.vantiv.com/2014/09/TriPos.Api">
<_errors>
    <error>
      <developerMessage>ERROR:POST error
EXCEPTION: Could not find a Configured PIN pad tethered to the lane specified in the request: 1
</developerMessage>
      <errorType />
      <exceptionMessage>Could not find a Configured PIN pad tethered to the lane specified in the request: 1</exceptionMessage>
      <exceptionTypeFullName>TriPos.Shared.Exceptions.LaneConfigurationNotFoundException</exceptionTypeFullName>
      <exceptionTypeShortName>LaneConfigurationNotFoundException</exceptionTypeShortName>
      <userMessage />
    </error>
</_errors>
<_hasErrors>true</_hasErrors>
<_links />
<_logs xmlns:d2p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" i:type="Logs">
    <log>TRACE:Attempting to retrieve PIN pad with laneId:1
</log>
    <log>TRACE:PIN pad with laneId:1 was found?[True]
</log>
    <log>TRACE:Creating a LaneContext for lane [1]
</log>
    <log>INFO:PinPadConfig for lane [1]: BaudRate:9600, ComPort:COM9, Driver:VeriFoneXpi, IpAddress:, IpPort:0, TerminalType:PointOfSale, IsUnattended:False
</log>
    <log>ERROR:POST error
EXCEPTION: Could not find a Configured PIN pad tethered to the lane specified in the request: 1
</log>
</_logs>
<_type>saleResponse</_type>
<_warnings />
<_processor>
    <expressResponseCode i:nil="true" />
    <expressResponseMessage i:nil="true" />
    <hostResponseCode i:nil="true" />
    <hostResponseMessage i:nil="true" />
    <logs xmlns:d3p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" i:type="Logs">
      <log>Could not find a Configured PIN pad tethered to the lane specified in the request: 1</log>
    </logs>
    <processorLogs xmlns:d3p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" i:type="Logs">
      <log>Could not find a Configured PIN pad tethered to the lane specified in the request: 1</log>
    </processorLogs>
    <processorRawResponse i:nil="true" />
    <processorReferenceNumber i:nil="true" />
    <processorRequestFailed>false</processorRequestFailed>
    <processorRequestWasApproved>false</processorRequestWasApproved>
    <processorResponseCode>Unknown</processorResponseCode>
    <processorResponseMessage i:nil="true" />
    <rawResponse i:nil="true" />
</_processor>
<approvalNumber i:nil="true" />
<isApproved>false</isApproved>
<isOffline>false</isOffline>
<merchantId i:nil="true" />
<statusCode>None</statusCode>
<transactionDateTime i:nil="true" />
<transactionId i:nil="true" />
<accountNumber i:nil="true" />
<binValue i:nil="true" />
<cardHolderName i:nil="true" />
<cardLogo i:nil="true" />
<currencyCode>None</currencyCode>
<entryMode i:nil="true" />
<expirationMonth i:nil="true" />
<expirationYear i:nil="true" />
<paymentType>None</paymentType>
<pinVerified>false</pinVerified>
<signature i:nil="true" />
<terminalId i:nil="true" />
<totalAmount>0</totalAmount>
<approvedAmount>0</approvedAmount>
<convenienceFeeAmount>0</convenienceFeeAmount>
<emv i:nil="true" />
<fsaCard i:nil="true" />
<subTotalAmount>0</subTotalAmount>
<tipAmount>0</tipAmount>
<cashbackAmount>0</cashbackAmount>
<debitSurchargeAmount>0</debitSurchargeAmount>
</saleResponse>

As you can see, an exception occurred (very similar to what we see with the debit card in store and forward mode) BUT triPOS returns a valid XML document that we can interrogate to determine what the outcome was and even allowing us to log the developer message as extra detail for trouble shooting purposes.

This is what we meant when we spoke about consistency in the triPOS responses.

Trust this clarifies what we are looking for from triPOS.

Regards,

Mark Shipman

Actions

dmeeker @ mark@vista on Jan 31, 2018 4:56 PM

Hi Mark,

There are a couple of things going on here:

Note that you have the VeriFoneXpi listed in the <driver></driver> section, but the Mx915 requires the VerifoneFormAgentXpi.

<terminalType>PointOfSale</terminalType>

<driver>VeriFoneXpi</driver>

</idleScreen>

</pinpad>

<host>

</host>

<store>

</store>

</serialLane>

Is the Vx805 still plugged into the same computer? If so, please unplug it, as I have found that you cannot have two of the VeriFone devices on one machine at the same time. Once you have unplugged it I recommend uninstalling and reinstalling the driver, to get it to recognize the Mx915.

Actions

mark@vista @ dmeeker on Feb 1, 2018 1:07 PM

Hi Daniel,

Thank you for the pointer about the different driver setting.

We were obviously not clear enough in our post.

We were not trying to solve the driver issue.

We are trying to show the inconsistency in triPOS's handling of exceptions.

In this example (incorrect driver setting), an exception occurs BUT triPOS still yields a valid XML document we can interrogate.

Contrast this with the debit card in a store-and-forward (network physically disconnected) situation. triPOS throws an exception And no XML document is yielded.

This situation then requires us to build an intimate knowledge of how triPOS works into our integration instead of always interrogating an XML document with a consistent structure.

Thanks, Mark Shipman

Actions

mark@vista Feb 21, 2018 2:44 PM

nsuess you've done it again :-((

How was my further question a "correct answer"?

Please refrain from marking things correct - I do review my Q's and the A's I receive and mark the appropriate ones correct.

This question is still open.

When will the triPOS management of an exception with a debit card in a "network physically disconnected" situation yield a valid XML document that we can interrogate?

Actions

mark@vista Mar 5, 2018 3:06 PM

When can we expect a response to our question about this triPOS defect?

"When will the triPOS management of an exception with a debit card in a "network physically disconnected" situation yield a valid XML document that we can interrogate?"

Thanks

Actions

7 Replies

dmeeker Jan 26, 2018 9:48 AM
Mark Correct
Correct Answer
Hi Mark,

This is the expected behavior. triPOS won’t know that it needs to switch to offline mode until it tries to reach out to Express. All the card read/payment type validation process is done before reaching out to Express and that’s why when triPOS determines if the used payment type is valid for a transaction, it thinks it is in a regular, non-store mode so it prompts you the payment type options. When triPOS tries to reach to Express and determines that it can’t get to Express, it switches to store and forward mode and tries to store the transaction. At this time, it will try to store the transaction and would do some validations (check for debit, etc) that’s why you got an exception. If you try to send another sale transaction and use the same card, triPOS will behave differently because it now knows that it is in store and forward mode and will automatically process the card as Credit if it is credit capable.
Like • Show 0 Likes0
Actions
- mark@vista @ dmeeker on Jan 31, 2018 1:43 PM
  Mark Correct
  Correct Answer
  Hi Daniel,
  While we understand the flow you are describing and have no issue with it, triPOS will achieve a much better result if Vista (and other integrators) are not required to engineer our integration to take account of a special case like this.
  Any other transaction seems to always yield a valid XML response.
  To be consistent, triPOS should also return a valid XML response in this situation indicating the transaction was cancelled.
  We can then process this in the same way as we do any other triPOS response.
  Many thanks,
  Mark Shipman
  Like • Show 0 Likes0
  Actions
- mark@vista @ dmeeker on Jan 31, 2018 4:49 PM
  Mark Correct
  Correct Answer
  Hi Daniel,
  Here is another example.
  We are trying to connect a MX915 on lane 1.
  Our SALE transaction receives this response:
  <?xml version="1.0" encoding="utf-16"?>
  <saleResponse xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://tripos.vantiv.com/2014/09/TriPos.Api">
  <_errors>
      <error>
        <developerMessage>ERROR:POST error
  EXCEPTION: Could not find a Configured PIN pad tethered to the lane specified in the request: 1
  </developerMessage>
        <errorType />
        <exceptionMessage>Could not find a Configured PIN pad tethered to the lane specified in the request: 1</exceptionMessage>
        <exceptionTypeFullName>TriPos.Shared.Exceptions.LaneConfigurationNotFoundException</exceptionTypeFullName>
        <exceptionTypeShortName>LaneConfigurationNotFoundException</exceptionTypeShortName>
        <userMessage />
      </error>
  </_errors>
  <_hasErrors>true</_hasErrors>
  <_links />
  <_logs xmlns:d2p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" i:type="Logs">
      <log>TRACE:Attempting to retrieve PIN pad with laneId:1
  </log>
      <log>TRACE:PIN pad with laneId:1 was found?[True]
  </log>
      <log>TRACE:Creating a LaneContext for lane [1]
  </log>
      <log>INFO:PinPadConfig for lane [1]: BaudRate:9600, ComPort:COM9, Driver:VeriFoneXpi, IpAddress:, IpPort:0, TerminalType:PointOfSale, IsUnattended:False
  </log>
      <log>ERROR:POST error
  EXCEPTION: Could not find a Configured PIN pad tethered to the lane specified in the request: 1
  </log>
  </_logs>
  <_type>saleResponse</_type>
  <_warnings />
  <_processor>
      <expressResponseCode i:nil="true" />
      <expressResponseMessage i:nil="true" />
      <hostResponseCode i:nil="true" />
      <hostResponseMessage i:nil="true" />
      <logs xmlns:d3p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" i:type="Logs">
        <log>Could not find a Configured PIN pad tethered to the lane specified in the request: 1</log>
      </logs>
      <processorLogs xmlns:d3p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" i:type="Logs">
        <log>Could not find a Configured PIN pad tethered to the lane specified in the request: 1</log>
      </processorLogs>
      <processorRawResponse i:nil="true" />
      <processorReferenceNumber i:nil="true" />
      <processorRequestFailed>false</processorRequestFailed>
      <processorRequestWasApproved>false</processorRequestWasApproved>
      <processorResponseCode>Unknown</processorResponseCode>
      <processorResponseMessage i:nil="true" />
      <rawResponse i:nil="true" />
  </_processor>
  <approvalNumber i:nil="true" />
  <isApproved>false</isApproved>
  <isOffline>false</isOffline>
  <merchantId i:nil="true" />
  <statusCode>None</statusCode>
  <transactionDateTime i:nil="true" />
  <transactionId i:nil="true" />
  <accountNumber i:nil="true" />
  <binValue i:nil="true" />
  <cardHolderName i:nil="true" />
  <cardLogo i:nil="true" />
  <currencyCode>None</currencyCode>
  <entryMode i:nil="true" />
  <expirationMonth i:nil="true" />
  <expirationYear i:nil="true" />
  <paymentType>None</paymentType>
  <pinVerified>false</pinVerified>
  <signature i:nil="true" />
  <terminalId i:nil="true" />
  <totalAmount>0</totalAmount>
  <approvedAmount>0</approvedAmount>
  <convenienceFeeAmount>0</convenienceFeeAmount>
  <emv i:nil="true" />
  <fsaCard i:nil="true" />
  <subTotalAmount>0</subTotalAmount>
  <tipAmount>0</tipAmount>
  <cashbackAmount>0</cashbackAmount>
  <debitSurchargeAmount>0</debitSurchargeAmount>
  </saleResponse>
  
  As you can see, an exception occurred (very similar to what we see with the debit card in store and forward mode) BUT triPOS returns a valid XML document that we can interrogate to determine what the outcome was and even allowing us to log the developer message as extra detail for trouble shooting purposes.
  This is what we meant when we spoke about consistency in the triPOS responses.
  Trust this clarifies what we are looking for from triPOS.
  Regards,
  Mark Shipman
  Like • Show 0 Likes0
  Actions
  - dmeeker @ mark@vista on Jan 31, 2018 4:56 PM
    Mark Correct
    Correct Answer
    Hi Mark,
    
    There are a couple of things going on here:
    
    Note that you have the VeriFoneXpi listed in the <driver></driver> section, but the Mx915 requires the VerifoneFormAgentXpi.
    
        <serialLane description="VX805 serial" laneId="0001">
          <pinpad>
            
            <terminalType>PointOfSale</terminalType>
            
            <driver>VeriFoneXpi</driver>
            
            
            <comPort>COM9</comPort>
            
            <dataBits>8</dataBits>
            
            <parity>None</parity>
            
            <stopBits>One</stopBits>
            
            <handshake>None</handshake>
            
            <baudRate>9600</baudRate>
            
            <isManualEntryAllowed>true</isManualEntryAllowed>
            
            <isContactlessMsdEntryAllowed>true</isContactlessMsdEntryAllowed>
            
            <idleScreen>
              
              <message>Beep! Beep!</message>
              
              <image>logo.jpg</image>
            </idleScreen>
          </pinpad>
          <host>
            
            <terminalId>0000001</terminalId>
          </host>
          <transaction />
          <store>
            
            <transactionAmountLimit>10000</transactionAmountLimit>
          </store>
        </serialLane>
    
    Is the Vx805 still plugged into the same computer? If so, please unplug it, as I have found that you cannot have two of the VeriFone devices on one machine at the same time. Once you have unplugged it I recommend uninstalling and reinstalling the driver, to get it to recognize the Mx915.
    Like • Show 0 Likes0
    Actions
    - mark@vista @ dmeeker on Feb 1, 2018 1:07 PM
      Unmark Correct
      Correct Answer
      Hi Daniel,
      Thank you for the pointer about the different driver setting.
      We were obviously not clear enough in our post.
      We were not trying to solve the driver issue.
      We are trying to show the inconsistency in triPOS's handling of exceptions.
      In this example (incorrect driver setting), an exception occurs BUT triPOS still yields a valid XML document we can interrogate.
      Contrast this with the debit card in a store-and-forward (network physically disconnected) situation. triPOS throws an exception And no XML document is yielded.
      This situation then requires us to build an intimate knowledge of how triPOS works into our integration instead of always interrogating an XML document with a consistent structure.
      Thanks, Mark Shipman
      Like • Show 0 Likes0
      Actions
mark@vista Feb 21, 2018 2:44 PM
Mark Correct
Correct Answer
nsuess you've done it again :-((

How was my further question a "correct answer"?

Please refrain from marking things correct - I do review my Q's and the A's I receive and mark the appropriate ones correct.

This question is still open.

When will the triPOS management of an exception with a debit card in a "network physically disconnected" situation yield a valid XML document that we can interrogate?
Like • Show 0 Likes0
Actions
mark@vista Mar 5, 2018 3:06 PM
Mark Correct
Correct Answer
When can we expect a response to our question about this triPOS defect?

"When will the triPOS management of an exception with a debit card in a "network physically disconnected" situation yield a valid XML document that we can interrogate?"

Thanks
Like • Show 0 Likes0
Actions

VX805 / triPOS store and forward issue: unexpected response

Outcomes

Related Content

Recommended Content