This guide is not for data acquisition, but for easier reporting of data discrepancies. You can either let your users report improvements or corrections right through your application while using the suggestion endpoint or do it on your own.
It is up to you whether you want to provide the option to report data discrepancies to your users, to allow reporting only to your employees, or not to implement it at all. We recommend its implementation to improve data quality for your further usage.
If you choose to implement suggestions, you will be working with a POST endpoint /suggestions with all the data you have available. All the parameters we need are listed in the documentation here.
There are many levels on which you can report, depending on how much information you hold.
Namely, the object named original refers to the specific transaction (API call) when you requested data about a transaction, transfer or payment. It provides us information about the exact query, the object sent and the response received. This also helps Tapix to identify all other affected records.
The object current describes the specific affected shops or merchants by their uids which are stored in your database.
Note that the more information you provide for both objects, the better the results. You do not have to provide both objects if you do not have the information.
Of course, the quintessence of suggestions is in the suggestion itself - so keep in mind that the better the description given in the parameter suggestion, the better results you may expect.
You can also use sandbox with samples from this guide or try the API on your own.
Following the documentation, provide all the information for the main objects as well as:
suggestion - the description of what information is mismatched and its correct valuesource - who the suggestion comes from - it can either be your employees (in this case use value partner) or your users (use value user)In this case, the message would look like the following:
{
"original":{
"url":"<tapixURL>/v6/shops/findByCardTransaction?merchantId=84591982&posId=TES44278&zip=N1%209DX&description=TESCO%20STORES%202789&city=LONDON&country=GB&mcc=5411",
"request":{
"merchantId":"84591982",
"posId":"TES44278",
"description":"TESCO STORES 2789",
"zip":"N1 9DX",
"city":"LONDON",
"country":"GB",
"mcc":"5411"
},
"response":{
"result":"found",
"handle":"0erPBQ5neagUElWYBK9ozG",
"shop":{
"uid":"0erPBQ5neagUElWYBK9ozG"
}
},
"timestamp":"2020-09-19T11:16:36+00:00"
},
"current":{
"shopUid":"0erPBQ5neagUElWYBK9ozG",
"transaction":{
"merchantId":"84591982",
"posId":"TES44278",
"description":"TESCO STORES 2789",
"zip":"N1 9DX",
"city":"LONDON",
"country":"GB",
"mcc":"5411"
}
},
"suggestion":{
"incorrectMerchant":false,
"incorrectLogo":false,
"incorrectLocation":true,
"incorrectCategory":false,
"text":"Wrong shop, should be Tesco store on 2 Monck St, London."
},
"source":"client"
}In return, you are rewarded with HTTP status 200!
There are times when you find yourself in a situation where you do not have access to the information about the original call (typically if you implement suggestions for your end users). In such case, you will only be able to send the parameter object current, such as in the following:
{
"current": {
"shopUid": "MmPdedgnvjXiRZnBJzJQKb"
},
"suggestion": "Wrong tag Bookstore!!",
"source": "user"
}And yet again, if everything goes well, you are rewarded with HTTP 200!
In this case, the information provided is sufficient for the Tapix team to make the correct data adjustments that will affect the records via the standard invalidation process. When the suggestion is taken on board and the referred object is invalidated, use invalidations to look it up and update or remap the record.
You can learn about integrating invalidations which serve to keep your data up-to-date or you can learn more about integrating and enriching card transactions, bank transfers or Open Data payments for additional data.