The user is not actually purchasing anything through our app.
The user is manually entering a record of what he purchased elsewhere.
I've used this kind of stock position tracker before. I hope to almighty Bob that he doesn't want us to implement an actual transaction processing component.
Meaning that I don't think that actual transaction processing is in scope.
Our app, if it's like similar-sounding apps, would take a manually entered record of a stock transaction and compare it to the publicly available record of the current price in order to tell the user his profit or loss.
Yeah. There are two different ways that these kinds of apps do this:
The user enters a stock symbol ("GOOG"), a purchase price ($10 per share), and a quantity (100 shares). The app records that and then every time the user visits the app, the app displays (currentMarketPrice - purchasePrice) * quantity and calls that the profit/loss for that position. (currentMarketPrice comes from a source like the Yahoo API.)
The user looks up a stock (say it's Google again, or whatever). The app shows the current price. The user clicks a buy button (usually it's actually a hell of a lot more complicated than that, with forms and shit for advanced purchase options). The app then proceeds to do almost exactly what I described in (1), but purchasePrice is set automatically based on the actual market price at the time of purchase rather than manually by the user.