Create BRL to EUR transfer feature

[prayagd]

As a user, i should be able to onramp and send BRL to EUR

Acceptance criteria

• On /transfer
• Show thee items, two inputs and one informational
  • First item, is called "Amount (BRL)", this would display the amount in BRL based on the EUR required
  • Second item, is called "EUR Amount". This is a input field, user should be able to enter the EUR amount to be sent to the receiver
  • Third item, is called IBAN. This is input field, user should be able to enter a valid IBAN.
  • Once all the fields are correct, enable the "Confirm" button.
  • Possible errors
    • User enters higher "EUR Amount" than available in the Nabla pool. Show error "Sorry, unable to make the transfer"
    • User enter incorrect IBAN. Show error "Incorrect IBAN"
    • All these errors should only be showed once the user clicks on the "Confirm" button
    • Show these error text below the button.

      Notes

• "Amount" should be calculated using the Nabla exchange rate for that pool, currently details missing
• Things not taken into consideration onramp fee, offramp fee, moonbeam fee, Nabla swap fee

LoFi wireframes

Technical Details

• There is only one API request involved here, the endpoint is in this ticket
• if this endpoint returns an error, then stay on this screen and display an error message, otherwise advance to the QR code screen

[prayagd]

Hey team! Please add your planning poker estimate with Zenhub @b-yap @bogdanS98 @ebma @gianfra-t @TorstenStueber

[ebma]

A few remarks:

Show QR code

We need to know the data that this QR code is supposed to encode. I suppose that PIX has some specific definition of parameters that the QR code needs to contain. @TorstenStueber do you know where we can find this information?

Mykobo would provide this data through an API, only the KYC'ed users by mykobo can recieve. Here IBAN would be used to verify that.

Did we agree on this now? Is this a final decision that we want to use the IBAN over the email address? Do we know if Mykobo can provide us with this data without violating GDPR?

• "Amount" should be calculated using the Nabla exchange rate for that pool
• Things not taken into consideration onramp fee, offramp fee, moonbeam fee, Nabla swap fee

We'll incorporate these fees at a later point in time though, right? The later point in time still being in scope of the PoC but not necessarily this ticket.

[prayagd]

Did we agree on this now? Is this a final decision that we want to use the IBAN over the email address? Do we know if Mykobo can provide us with this data without violating GDPR?

Yes this was confirmed by Mykobo, they will build and API to share this info based on the IBAN provided. Whether GDPR complaint or not @annatekl can you please help answer that.

We'll incorporate these fees at a later point in time though, right? The later point in time still being in scope of the PoC but not necessarily this ticket.

Exactly, we want to make progress and we will incorporate the fees at a later point once we get clarity, this is in the scope of the PoC

[annatekl]

@ebma @prayagd i need to check that about the GDPR part with MYKOBO

[TorstenStueber]

A few more remarks from me.

We need to know the data that this QR code is supposed to encode

@ebma there is some more information here. The pix code encodes the amount, the bank account of Transfero and a timeout.

Mykobo would provide this data through an API

@prayagd what data? The IBAN? No, they won't. They can at most confirm that an IBAN is in their system and KYCed (to be confirmed, this could be a problem due to GDPR).

First item, is called "Amount",

We should also write BRL (or R$) somewhere to make it fool proof that this is the BRL amount

Code validity is assumed for 10 minutes

We don't need to assume this, we can explicitly specify the timeout when creating the QR code

Things not taken into consideration onramp fee, offramp fee, moonbeam fee, Nabla swap fee

Can we already create a ticket for this to keep track of remaining effort?

More remarks

• is this a pure UI ticket?
• I would propose to split this ticket into two: one for the view with the input fields, one for the generation and display of the QR code. For this reason I will not estimate this ticket yet

[annatekl]

@ebma @prayagd i need to check that about the GDPR part with MYKOBO

@TorstenStueber 'the data owner would have consented for information to be shared with the processor of the information or their partners. Nevertherless we would not share the content just a confirmation of the status i.e. KYC;d or not KYC'd'

[prayagd]

@prayagd what data? The IBAN? No, they won't. They can at most confirm that an IBAN is in their system and KYCed (to be confirmed, this could be a problem due to GDPR).

@TorstenStueber Updated

We should also write BRL (or R$) somewhere to make it fool proof that this is the BRL amount

Updated this too

Can we already create a ticket for this to keep track of remaining effort?

Sure, here is the placeholder ticket. Will add in details once i get the inputs

is this a pure UI ticket?

Yes mostly

I would propose to split this ticket into two: one for the view with the input fields, one for the generation and display of the QR code.

Makes sense, new ticket here

Also added some error possibilities.

[TorstenStueber]

Yes mostly

@prayagd that's a crucial question: if we split backend and frontend into two repositories, then tickets would also be pure frontend and pure backend tickets. Is that actually what we want going forward? In that case we should already have a backend ticket ready and link to it here and ensure that these tickets complement each other.

[prayagd]

@TorstenStueber i think so this is now resolved, we dont have two repos for frontend and backend but we would surely need a ticket in this repo for the backend work

[TorstenStueber]

Agreed!

[TorstenStueber]

I changed the description and removed references to the offramp provider.

[TorstenStueber]

@prayagd we should move this to icebox.

[TorstenStueber]

This ticket is meant for an obsolete prototype. Closed.