Identifiers

API fields: payment.id, transaction.id, order.id

There are 3 different fields with an identification function. Although similar, each plays a distinct role in the platform.

• Payment: represents the payment code. It must be provided when creating a payment and used when later updating the same payment. This is usually an internal code used to group automatic transaction retries. If not provided, a code will be generated by the platform.
• Transaction: optional transaction code. It represents an attempt to communicate with a financial institution. You should send an internal code from your system whenever possible. Otherwise, send a concatenation of the connector code plus the unique code generated by the connector (TID, NSU, etc). For example: 31231-9957812331231. Even so, if it is not possible to generate a unique code, do not send the field.
• Order: optional order code (subscription, cart, etc). This code will be used to track retries made across multiple different payments.

We understand that often not all of this information is available and that a natural solution is to repeat the same code two or even three times in the fields above. We do not recommend this practice, since the fields are optional. When the information is not available, avoid sending data just to fill the field.

If the same code is sent repeated across multiple fields, there may be consequences for the quality of the analysis. For example: when the order identifier receives the same value as the payment identifier, the platform will erroneously report that the number of attempts per purchase is always 1. In this case, the ideal solution is to find an identifier that represents the order (or subscription, etc) across all payments that the customer (or system) may make.

As a last resort, if it is not possible to obtain reliable information, do not send the optional field. This way, the analyses will not be negatively affected by data that does not represent reality.