Managing stellar customer accounts via federation and memo field, good practices?

Question

I would like to create an asset that can be traded for particular asset(s) only so I decided to take approach where I use a single account to manage customer balances by using federation server and memo, one of the two ways suggested in Stellar guide documents:

Use federation and the memo field in transactions to send and receive payments on behalf of your customers. In this approach, transactions intended for your customers are all made using your base account. The memo field of the transaction is used to identify the actual customer a payment is intended for.

Latter on in the same guide are explained flows for performing payments (send/receive) on behalf of customers but there is no exact explanation of how is memo field used to manage this payments. Should we use single memo for every customer and map publicKey > amount? What events should we listen for and how should we react on them?

Are there any guides out there? I have failed to find any.

Answer 1

We implemented federated accounts for our users as follows:

• All our users have one or more account codes that they can use together with our domain name to form a federated address of the form accountcode*inbot.io
• We have implemented a federation endpoint in our API that responds with the appropriate stellar address and memo in response to a query for a federated address.
• We have set up a compliance endpoint as well that allows people to check whether we will be able to process their transaction before they send it. We only accept our own InToken for our users and only for users that we have cleared for aml/kyc. Using this API is optional for users but it helps them prevent sending us wrong transactions.
• The federation and compliance endpoints are advertised in our stellar.toml on our website. So people can figure out from just the federated address what endpoints to call.
• We regularly check the stellar accounts for new payments that we have not yet processed and look up the correct user using the account code in the memo field.
• Any incoming payments that we can't find a valid user for are simply added to special internal account so we can take appropriate action. We don't have automated refunds currently but we might add that in the future if there's a need.

If you are going to do this, ignore the demo servers advertised on stellar.org. They are nice as a demo but useless for product development. Most of their documentation is about how to configure them instead of how they actually work. Once you dive into that, you'll likely come to the same conclusion as me and others I've talked to: it's a greenfield project with its own databases and a bunch of implementation choices that may or may not be something you are comfortable with and that has no integration points with whatever else you are running. Fixing that has the same or larger complexity as merely implementing two very straightforward endpoints in your own API.