The challenge for the developer is twofold; 1) Understanding the real time availability of the inventory at the retail partner and 2) Supporting the payment provider of the retailer. In the desktop world this was solved by a straight up affiliate redirect. You arrived at the retailer page and saw your product in a shopping cart or close to it. Of course if inventory was poorly synced you occasionally got an error. This is still pretty common with things like airline metasearch services where the cheap ticket can be gone. Either way inventory was managed. Then you entered your payment method on the retailer site and it was processed by their backend processor.
In the mobile world with mobile optimized apps those redirects don't work. So app developers want to make the payment experience feel like it's happening "within the app" Twitter, Facebook, Pinterest and others all then had to solve for the inventory + payments challenge. Defaulting to Stripe can be problematic if the retailer already has a different payment processor relationship in place. By solving for the inventory piece I suspect Stripe is hoping to help drive momentum around overcoming the processor objections.
Full disclosure I work at Spreedly where we help solve for the payment dilemma (not inventory) by allowing developers to work with a wide range of payment processors and/or affiliate API's.