When the user swipes their card, our application checks the "active" asset selected and if the user balance in that asset, for example bitcoin, is greater or equal to the transaction, the card instantly will be credited the amount from our Mastercard Settlement Account held with the issuing bank to pay the transaction (Real-Time Loading + External Authorization Method), and then deducted from our "active" selected asset.
This would require that the payment process interact with your application somehow, I genuinely do not see where this is taking place in the transaction flow. I'm going to have to assume that the issuing bank is offering a service whereby its systems provides for that prior to the authorisation message.
In any event, my concern is regarding the exchange rate being fixed prior to the transaction by way of the user 'selecting' it in the app, as opposed to a real-time rate, and is both confirmed by you,
The whole point of this service was that users would be able to store the cryptocurrency safely and for the transaction to deduct the equivalent amount only as and when card expenditure is triggered, but this 'selection' process you describe can only be for the purpose of setting a fixed cash value, which means there is no benefit over existing cryptocurrency card services.
- That is correct, and that is how the system works.
...and then contradicted
When you, as the user, makes a swipe/online transaction, at that instant moment we are giving you a market exchange rate to fiat conversion that allows the charge to be approved. We also have a formula to configure slippage as we use numerous exchanges connected to CCE via APIs to always perform the safest/closest transaction exchange.
So which is it? Does the 'selection' process fix the rate to be whatever Centra is offering until the cryptocurrency is 'deselected' by the user, or does it provide for a real-time exchange rate at the time of the transaction?
