How to properly integrate payment services with different business rules for transaction IDs?

Question

API

Hello!
Three years ago, my team and I created internet banking for a bank and have been supporting it ever since. During this time, we have a lot of any integration with external systems:
* IBSO (current accounts, deposits, currency conversion);
* Card processing of our bank
* Third-party card processing
* Several service providers
* Partner car loan systems
* Several microfinance organizations

The user can:
1 make transfers
* Card-to-Card,
* Card-to-Account/Deposit,
* Account/Deposit-To-Card,
* Co-Account/Deposit-To-Account/Deposit;
2 Make payments for any service (telephone, utilities, steam) from any of the above sources.
3 Repay loans;

Our architecture is microservice, for each integration there is a gateway - a separate software (service), which has its own database and its own accounting of all transactions passing through it. There is also one service coordinator who generally decides which gateways participate in the payment and in what order, it is he who generates the UUID - a common identifier for all participants, which is used by everyone else.

The process, at the level of OUR services, is something like this:
1 a payment order arrives at the service coordinator;
2 the service coordinator identifies the type of payment order. The list of participating gateways follows from the order type;
3 the service coordinator finds out from all participants the readiness to accept payment, this also includes checking for the right to conduct payment orders by the user-initiator;
4 the service coordinator instructs the participating gateways to execute their part of the transaction;

The process, at the level of GATEWAYS interaction with the EXTERNAL API, fits into two options:
1 We send our ID (UUID) to create a transaction
1.1 We receive a response that is not erroneous
1.2 We schedule the transaction status BY OUR ID
2 We send our ID (UUID ) to create a transaction
2.1 We receive a response containing EXTERNAL_ID;
2.2 Scheduled polling the transaction status BY EXTERNAL EXTERNAL_ID.

Somehow, ALL of the integrations we've done over the past three years have allowed us to use our UUID in trades. There was indeed one case where the external system only expected an INTEGER type for an identifier, we solved this by creating a table with an integer key filled with AUTOINCREMENT. Our UUID came to this gateway, which was stored in the AUTOINCREMENT table, and then an integer ID was sent, which was mapped to the UUID.

Now to the problem!
A task arrived (more precisely, 5 tasks) to integrate with 5 payment systems at once, and none of them accepts UUIDs as identifiers on our part! For different reasons, with different business rules.
1 For some, the identifier must contain ONLY NUMBERS, it can be MAXIMUM 10 characters long and MINIMUM FOUR!
2 others have a string identifier of 30 characters (UUID will not fit);
3 the third has a string identifier, MAXIMUM 15 characters, but MUST contain at least one digit, so it’s more profitable to send only numbers here;
4 for the remaining two, everything is simple: integer 10 characters

I want to know how it is generally customary to properly resolve such an integration? Are there best practices? For some reason, I don't want to create a separate table with AUTOINCREMENT just for mapping UUID-> INT, but I don't see any other options.

Separately, I ask you to suggest how you would implement the generation of identifiers for the rules described in paragraph 1.

Thank you very much.

Answer 1

Are the services mutually independent?
you do not need to generate your own ID for each, just one digital ID that you do by autoincrement, so feed it to them, where there is a minimum limit, add 9999 to the left or right...
When you work with other people's services and cannot affect them, nothing but independently maintain their own bunch of parts of their base with their own, and thank God that you have only one identifier! and not so that it may be necessary to start and monitor the state of a part of the database from a third-party service.