If you control the client device, it's not really suitable as a second factor in a two-factor authentication system.
To elaborate: on a PIN debit payment, for example, there are two factors - something you have (the debit card) and something you[1] know (the PIN). In the case of authorizing the purchase of an app, you obviously have physical access to the device, or else you wouldn't be able to get to the checkout screen. For an actual second factor in a MFA scheme, it would be necessary to have a _different_ device that only the user with authority to make a purchase would have access to.
One could argue that if the device is PIN-locked, this is sufficient; however, in this case, you're replacing a physical factor (having the device) with a knowledge factor (knowing the unlock code). Combined with the account password [2], you still only have one-factor auth, it's just two steps. This is like most banking logins: there's a single authentication factor - knowledge - but two different pieces of data are necessary.
Worse yet, that "mother's maiden name"-type info tends to be a) relatively easy to access as an unauthorized user and b) used to authorize password reset, thereby reducing the security of a possibly-great password down to your facebook account's privacy settings.
Suffice to say, proper MFA support when the device often used as the physical factor is part of what's being authenticated is non-trivial, and almost by definition requires additional hardware. Perhaps some sort of NFC/RFID tag that you'd keep in your wallet, or a less clumsy equivalent of an RSA keyfob (which is where TOTP came from in the first place). But the key takeaway here is that you cannot use the device being authenticated as part of the authentication scheme.
[1] and only you, I hope! otherwise there's no point.
[2] or worse, not, as some have suggested for free or even paid apps