A merchant represents the overall brand or company, such as Tesco or Starbucks. A shop refers to a specific outlet or online store belonging to that merchant, such as a particular Tesco branch located on a specific street. Every shop belongs to exactly one merchant, while a single merchant may be associated with many shops, which is why the two levels are distinguished within our data model.
You can get access to the Sandbox by simply registering on the Tapix Developers Portal. Once registered, you will have access to the Sandbox under the Sandbox tab in your account. It's useful for the very first integration checks, such as exploring the API, understanding request and response structure, and trying predefined examples. It is not intended for realistic coverage testing or evaluating enrichment quality on your own data. For that run a dedicated proof of concept with a representative data sample. For more information, please contact sales.
Tapix can enrich a wide range of payment types, including card transactions, account-to-account (A2A) transfers such as SEPA, UK BACS/Faster Payments, CERTIS, and JoPACC, as well as P2P transfers, QR code payments, and Open Banking Data/PSD2 transactions or any local standard, each through dedicated endpoints. We also support other payment types beyond these, so if you don't see yours listed, please contact sales or your Implementation Manager to discuss your specific needs.
Yes, our public status page at http://status.tapix.io shows real-time service health, alongside a dedicated /health endpoint you can poll directly.
For card transactions, description, merchantId, posId, city, country, and mcc are all important for reliable matching. We cross-check these parameters against each other, because a single parameter on its own can be misleading. For example, a description may be shortened or generic, or a merchantId may be shared by several shops. The combination of parameters is what allows us to identify the right merchant and shop. The more complete and unmodified the data you send, the higher the chance of successful matching. Required and recommended parameters vary by payment type, so for the full list of parameters for each transaction type, see our documentation.
Check with your payment processor first, as most parameters come from the raw transaction data they provide (such as ISO 8583 fields). If a parameter is genuinely unavailable, omit it from the request entirely rather than sending it as an empty field. Let us know which parameters are missing, and we'll recommend the best approach based on the data you have available.
Use refresh=true for invalidation purposes, when you intentionally need Tapix to reprocess a transaction or mapping that has already been enriched. Adding this parameter tells Tapix not to treat the request as a duplicate, but to refresh the enrichment and update the related data. Do not use refresh=true for every standard API call; use it only when the purpose of the request is to invalidate or update an existing enriched result.
Use cache expiry if you prefer a simpler setup and don't need your historical transaction mappings to stay fully up to date. It periodically re-fetches all your stored shops and merchants regardless of whether anything changed, resulting in a straightforward setup but bulkier traffic.
Invalidations are recommended when data accuracy over time is a priority. This approach polls daily and re-fetches only the records that have actually changed, resulting in lighter, more consistent traffic. For details, see our Data update mechanism guide and the API documentation.
For data-quality issues, such as an incorrect merchant, logo, or category, use our /v6/feedback endpoint or contact datasupport@dateio.eu. For technical bugs or API errors, contact itsupport@dateio.eu with the relevant details, so we can investigate quickly.