Mini spike on onramping params

[twblack88]

OnRamping is still really country even though we've made it prominent inside of the app now. As part of phasing in better improvements, one thing we could do is see if we can touch more of the transaction surface from successful onramps.

What needs investigation? What's the problem to understand?

If we're able to get back inbound transactions from onrampers, we should be able to shove that into our notification server or at least feed it back into the app in some form or fashion. When you do actually successfully on-ramp and struggle through that whole process, you don't feel completely out of the loop.

AC

• spike into onramper and banxa successful transactions to see what kind of data we get back
• check on polling and websocket support to see if they support something we can listen for
• cross check on our unchained or new fancy services to see if we can jeet this data into notifications in any way

[NeOMakinG]

Onramper:

• Not sure the redirect url is passing the txId, that would be a usecase so we can poll for the TX status on the front end
• If we cant do that: we can always leverage our backend, initiate a webhook on onramper side, add a endpoint that would receive the calls, match the wallet address with our internal user ids, if yes then send a websocket event or poll on the front end side to retrieve the TX/match it
• txId is internal from onramper here so this is the challenge, we need a way to retrieve it, webhook is the first class choice here and would be better than anything… so we are dependent on our backend

Banxa:

• Callback mechanism (like onramper) but they are 100% allowing us to get the orderId from the front end, so this would be usable without the server
• We can always use the webhooks with the same mechanism than Onramper so it would be quite convenient to use the backend for this as we would do with onramper, with a mapping
  
  

Both has endpoints to retrieve the order status, that would be the flow:

• Receive data from webhooks
• Retrieve order status
• Create the new object in the db (would be something like "RampTransaction"
• When it resolve, send notifications + update through websocket or poll on the front end side

Conclusion:

• I think the microservices integration would be more robust, allowing us to send notifications on user phones and make the integration easier
• Second solution would be to verify that onramper is pushing parameters through our callback url and we could do it on the front end (but it would be harder to maintain and sending notification would be harder too)