1. Introduction

This section contains a brief introduction on the Physical Tid Api and its purpose.

1.1 Problematic factors of initializing a POS terminal

The initialization of POS terminals has always been a complex process. There are many different terminal manufacturers with different configurations which can prevent an automatic and sustainable setup.

The biggest flaw of the current process is the terminal authentication. Regularly, The British Card Association releases a set of authentication numbers to the card acquirers (Rapyd in this case) which distributes these numbers to their partners. Rapyd receives these authentication numbers regularly and distributes them to partners in bulk instead of assigning each and every merchant. This process can cause authentication numbers to be lost. This flaw is quite costly and there is a great risk of error when these numbers are being maintained in many different places.

The Physical Tid Api solves this by offering a single touch point, both for the acquirer and the partners when it comes to POS terminal authenticaton. This solution saves time and money and makes the terminal authentication much simpler. Rapyd will maintain the authentication numbers in a centralized database and partners can fetch the numbers and assign to a POS terminal that each merchant has.

1.2 The API

The API consists of a single endpoint where you POST a JSON payload consisting of agreementId and a terminalId (and optionally a physicalTid in cases where you have some sort of maintenence on the tids yourself). The next chapter will cover how the payload is set up with code examples and an API key for testing purposes.