Add SEP-24/SEP-6 communication between client_domain and anchor

[jopmiddelkamp]

What problem does your feature solve?

As a non-custodial wallet, tracking the status of client deposits and withdrawals can be challenging. We implemented a polling mechanism to fetch status updates, but this approach has proven inefficient, as it generates numerous unnecessary calls to our partner’s services. Additionally, receiving these updates on our back-end gives us the ability to send notifications to our users device without having to keep it awake most of the time.

What would you like to see?

We would like to add some interaction between the anchor and the client domain. The way we see this possible is via the following steps:

1. [Client Front-end] is requesting SEP-10 challenge with client_domain (belonging to [Client Back-end]) from the [Anchor Back-end]
2. [Client Front-end] signs the challenge
3. [Client Front-end] sends the challenge to the [Client Back-end] to sign the transaction
4. [Client Front-end] sends the challenge to the [Anchor Back-end] to verify the transaction
5. [Anchor Back-end] reads out the client_domain and reads out the TRANSFER_SERVER_CALLBACK_URL from the SEP-1 data
6. [Client Front-end] receives a JWT
7. [Client Front-end] requests a deposit from the [Anchor Back-end] via the JWT
8. [Anchor Back-end] sends updates directly to the TRANSFER_SERVER_CALLBACK_URL
9. [Client Back-end] can now send (silent) notifications to the [Client Front-end]

Legend:

• [Client Front-end]: The non-custodial wallet application
• [Client Back-end]: The back-end server belonging to the Client Front-end
• [Anchor Back-end]: The back-end server belonging the the Anchor

What alternatives are there?

The background worker we’ve built feels cumbersome and unnecessarily complicates the process, even though it shouldn’t be this way.

[JakeUrban]

Hey Jop, what you're describing is already supported in SEP-24 and SEP-6, although looking at the specification I think we should make this more clear.

The specification allows you to add an on_change_callback URL parameter to the webview URL returned by the anchor. If the anchor supports providing these callbacks, it will send the transaction object to the specified callback URL whenever the transaction status changes.

However, we've found that the vast majority of anchors do not want to support sending callbacks to URLs provided by clients in API requests on a per-transaction basis, which has a few security concerns. Instead, the anchors that do support callbacks, including MoneyGram, ask clients to provide a single callback URL they can use to send all transaction updates during the onboarding/integration process.

[Ifropc]

Instead, the anchors that do support callbacks, including MoneyGram, ask clients to provide a single callback URL they can use to send all transaction updates during the onboarding/integration process.

It could be a good idea to update SEP-1 specification to include the callback url there. The main issue with this approach is that the majority on anchors have some kind of whitelisting process, which makes having the entry in the toml file obsolete, as the anchor and wallet would have a direct line of communication anyway (assuming there's a whitelisting process)