Hi, when integrating towards the SOAP API (LitleXML) echeck, since it is possible to identify the transaction through transactionid and orderid fields, could the same request be sent twice without risk of double charges?
Regards,
Hi, when integrating towards the SOAP API (LitleXML) echeck, since it is possible to identify the transaction through transactionid and orderid fields, could the same request be sent twice without risk of double charges?
Regards,
Hi Renan,
We do have duplicate transaction detecting (see Duplicate Transaction Checking v1.7).
Briefly, if you send a duplicate transaction (except Online Auths), we detect it. If you are using version 9.x or below and submit the transaction as an Online transaction, the a duplicate (attribute) flag in response message will be set to true and the body of the message will be the response returned for the first transaction. If you are using version 11.x or above, you will get an approved response, but the duplicate is still blocked and shows up in the Declined Transaction Report (SSR) the next day.
Tom
Yes, checking the schema provided from vantiv
com/litle/schema/EcheckSale, the 'litleTxnId' is not there;
in com/litle/schema/Capture for example, you have the field present.
Is this the right place to request the bugfix? Otherwise, could you provide guidance?
Regards,
Hi Renen,
Before I answer your question, I'd like to point out that if you are just now coding to our platform, you should be coding to V12.6 of the schema. Version 10 is old. You can find the current guide for V12 here: Worldpay cnpAPI Reference Guide API 12.10, V2.12 .
So, the litleTxnId, now cnpTxnId in V12, has many uses, primarily for tracking/look-up (in iQ) and linking transactions. For example (linking), if you send an Auth, you can follow it by a Capture and include the cnpTxnId. Our system looks up the Auth and uses the its info to populate the (network) required info on the Capture. This simplifies the Capture XML message, eliminating the need to repeat all the info you sent in the Auth.
You don't see it in the echeckSale request, because there is nothing to link it to. There is no concept of an Auth when dealing with eCheck/ACH transactions. The XML message contains all the necessary info.
As for Dupe Checking of Online transactions, it is the id attribute of the transaction that the system uses as one of the parameters it checks (see below). You should use a unique value for each unique transaction. If you submit the same transaction twice, it would have the same id attribute.
<echeckSale reportGroup="reportGroup" id="anotherId" customerId="customerId">
The cnpTxnId only comes into play if there are linked transactions involved, such as an Auth /Capture link or a Capture/Credit link. This is because information is looked up in the linked transaction, such as card number or account number in the case of eChecks. For example, if you submitted an echeckCredit, you would use the cnpTxnId to link back the the echeckSale transaction.
Tom
Tom,
thank you very much for your quick answer.
We are maintaining some legacy integrations, so the reason we use the 9.3 version. After your explanation, I understood the concept of the cpnTxnId.
I'm doing the same request, using the same id: <echeckSalesResponse id="anotherId" reportGroup="reportGroup">
Although I receive an approved answer I do not receive the flag on the response as mentioned before:
If you are using version 9.x or below and submit the transaction as an Online transaction, the a duplicate (attribute) flag in response message will be set to true and the body of the message will be the response returned for the first transaction.
I receive the same answer with a different littleTxnId:
For the same request body
First Response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<litleOnlineResponse xmlns="http://www.litle.com/schema" version="9.3" response="0" message="Valid Format">
<echeckSalesResponse id="anotherId" reportGroup="reportGroup">
<litleTxnId>416890280847542301</litleTxnId>
<orderId>42</orderId>
<response>000</response>
<responseTime>2018-12-04T14:21:58.128</responseTime>
<message>Approved</message>
</echeckSalesResponse>
</litleOnlineResponse>
Second Response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<litleOnlineResponse xmlns="http://www.litle.com/schema" version="9.3" response="0" message="Valid Format">
<echeckSalesResponse id="anotherId" reportGroup="reportGroup">
<litleTxnId>410403481751133764</litleTxnId>
<orderId>42</orderId>
<response>000</response>
<responseTime>2018-12-04T16:15:02.276</responseTime>
<message>Approved</message>
</echeckSalesResponse>
</litleOnlineResponse>
So can we consider the transaction not duplicated in the case?
Regards,
Are you testing in Sandbox or Pre-Live. I don't believe the Sandbox has Dupe Checking, since it doesn't persist the transactional information. On the other hand, if you are in Pre-Live and using V9.x, dupe Checking should work as outlined in the snippet you included in your last message.
Please let me know where you are testing. If it's Pre-Live, I'll have enter a ticket for someone to look at it, because something must be broken.
tom
PS...Sorry for misspelling your name in my last reply. My bad :O(
We are using the following url:
https://www.testvantivcnp.com/prelive/communicator/online
No worries about the spelling.
Thank you very much.
Hi Renan,
We do have duplicate transaction detecting (see Duplicate Transaction Checking v1.7).
Briefly, if you send a duplicate transaction (except Online Auths), we detect it. If you are using version 9.x or below and submit the transaction as an Online transaction, the a duplicate (attribute) flag in response message will be set to true and the body of the message will be the response returned for the first transaction. If you are using version 11.x or above, you will get an approved response, but the duplicate is still blocked and shows up in the Declined Transaction Report (SSR) the next day.
Tom