20260121-Services-Provider-Architecture-Model

Background

The question was raised whether new remittance/pay-in provider implementations should be their own services, or live in the relevant services. This came out of the creation of be-bitso and be-cobre services being created

Decision

• be-bitso and be-cobre are fine as their own services
• mf-remittance providers will remain there unless there is reason to move to their own service, for eg. scaling
• new providers to be evaluated on a case by case basis:
  • if its remittance/payin only - to live in the relevant service (moneyflow/cryptofunding) as a provider
  • if its both - new service
  • if its one for now but could be both in future - consider how far in future this change is (available/in dev/maybe one day) and decide using the above

Reasoning

• Having a new service where the functionality is shared or called from multiple services makes sense. This avoids duplication of code like webhook handling, webhook parsing, auth, http client etc. It also avoids conflicts between services like for eg. where asking for tokens invalidates previous tokens on provider side

• mf-remittance already follows the model of having remittance providers as adapters within itself. Migration is being avoided unless there is a benefit to be gained by doing so (eg. scaling needed)

• New providers should be evaluated critically as to where their code should live, rather than just adding it somewhere because its easy.

Consequences

Services as they are today remain unchanged, however there is an evaluation path available now for future implementations