This is a multi-faceted question. And I'm sorry but much of this answer consists of questions you need to answer:
1. PCI Compliance
Compliance with any of the 15 PCI standards is a contractual requirement, so firstly it is important to understand who is asking you to comply with which PCI standard. I'm going to guess that may well be Novopayment which appears to be a Visa Member and so has an issuing license. Again, a guess, but it will probably be just compliance with PCI DSS - the Card Production standard is the other one that is most commonly applicable in issuance, BUT it is focussed very much on physical plastic.
The next question is whether you actually have a PAN or an Visa Digital Token complaint with the EMVCo Token Specification. If it is a Token, PCI DSS is not applicable see PCI SSC FAQ 1326 How does PCI DSS apply to EMVCo Payment Tokens? https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-does-PCI-DSS-apply-to-EMVCo-Payment-Tokens
Finally, there may be separate Visa security rules that you are required to comply with that are separate from any PCI standards compliance.
All that said, because an issuer is generally going to bear the cost of any fraud caused by the issuer's poor data security, card brands (i.e. Visa) tend to be more relaxed about telling issuers what to do. But my starting point would be to look at your contract and to ask Novopayment.
2. Security and Compliance
Let's assume you have a requirement to comply with PCI DSS.
Generally a consumer's (ie a cardholder) own device is outside the scope of any PCI requirements, however the app provided by an entity in the payment ecosystem is not.
Also, if your internal infrastructure could "affect the security of cardholder data" then it too could be in scope of PCI DSS's requirements. Only a Qualified Security Assessor would be able to advise you.
For the app an assessor would look to make sure that the relevant parts of PCI DSS requirement 6 were in place.
Although not specifically focused on your issuance use case, the PCI SSC guidelines PCI Mobile Payment Acceptance Security Guidelines for Developers https://www.pcisecuritystandards.org/documents/PCI_Mobile_Payment_Acceptance_Security_Guidelines_for_Developers_v2_0.pdf contains useful information on developing mobile apps that protect cardholder data.
I'd also highly recommend that you start to follow the PCI Secure Software Standard https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_1.pdf because in the future that is a standard that you will be most likely to required to comply with.
3. Security
In addition to @mentallurg's very valid security observations.
In your question you stated:
brings back the hashed PAN, CVV and ExpDate we decode it and show it to the user but don´t store anything.
Hashing is intentionally a one-way, non-reversible cryptographic function. I guess you don't mean hashed but encrypted and your app has the capability to decrypt it. The reason I mention this is if someone supplies you with a hash of a PAN their assumption is that you don't need access to the PAN itself, and that you wouldn't try to reverse (e.g. brute force) the hash back to the PAN. You should check this!