[Security] Is this library secure?

[Borwe]

From what I can see, it requires the user inputting their callbacks, Passkeys, and even Business shortcodes.
This info cannot surely be mangled by anything whether proguard, or R8 or yGuard, which I presume some users
will even put the variables holding this info in static final Strings 🤣 making it easier for attackers.

If someone is to de-compile an app using this library what security is put into place to avoid leaking out the data stated on top.

EG:
A hacker decompiles, and just greps output for "https://" to get callback urls, and then begins sending dummy requests to it,
now if the user of this library has it that that callback is used to validate a purchase, a hacker can do unlimited purchases without paying a single coin.

This is just an example, I assume there are many more attack vectors.

Maybe users of the library can be adviced to not store those variables directly in their app but pull them from some REST Api in an encrypted format, decrypt on the device and use it?

[e-kibet]

I total agree with the above info.

I would suggest we have the .properties file in which the library will be reading the credentials needed and therefore would provided another level of security.
Alternately we can also have a api-key as third set of security for a library

[jumaallan]

Thank you for the feedback. Will circle back on this

[langsmith]

Any update or progress on this?