As the other answers have said, and as I redundantly commented above, you actually are very much still covered by PCI Requirements concerning the security of credit & debit card information that is handled on your network. One area of the PCI Requirements set for merchants contains the mandate that if you store cardholder information for any reason it must be either encrypted or tokenized. (For general reference, tokenization as referred to here means where the payment processor receives the cardholder's info the first time he or she uses it at a merchant and then gives the merchant a generated "token" id that the merchant can store and provide to the processor in future transactions as a substitute for having to recall a buyer's real credit/debit card info from storage. The token protects the buyer because any token can be used only by that one specific merchant to make future charges.) Tokenization is fine and dandy as a way of not storing plain-text Primary Account Numbers on your systems; if you do it right it fulfills the rules in PCI Requirement area #3 that cover the storage of card information*. But--here's the big thing-- the other rules in the other 11 Requirement areas still also apply to you. Tokenization (again, as we're talking about it here) just gets you past dealing with the section #3 rules about storing card information.
It seems like you might be getting tokenization as a means to not store cardholder Primary Account Numbers a little mixed up with the concept of Point-to-Point encryption (aka "P2PE" or sometimes "on-swipe encryption"), which deals with the protection of card information as transaction occurs. Well-implemented P2PE is a wonderful thing; the card reader or terminal that reads the purchaser's card when he or she swipes it (or "dips" it, with the EMV/chip cards now being finally transitioned to in the U.S.) encrypts that information before it ever leaves the reader/terminal. The encrypted card information flows from the reader to you mobile app or fixed Point-of-Sale setup and then is sent along to your payment processor's network, where only there is it decrypted so the purchase transaction can be processed. Because none of your equipment as a merchant ever sees an unencrypted card number or other vital data during a transaction there's no possibility a cyberthief can steal it from you. You never had it to steal to begin with. For this reason, the PCI Requirements allow a merchant using P2PE properly to avoid putting the merchant's computer systems under the scrutiny of 10 of the 12 PCI Requirement areas. Note, however, that even here not all PCI rules are discarded; the merchant must comply in providing physical security for the areas where the card terminals/readers are used and/or stored and in issuing various policies about information security to the merchant's employees/etc.
In your situation, unfortunately, as Andymac explained very well you couldn't qualify to get out from under those PCI compliance areas that merchants using P2PE don't have to worry about. Your computer, whether smartphone, PC, or anything else, "sees" and handles unencrypted credit/debit card info when it comes from the card reader. Moreover, any setup like that obviously couldn't be further specifically approved by the PCI people to become an official "Validated P2PE Solution" of the kind you need to have if you want to use that sweet reduced-question P2PE-HW SAQ compliance assessment.
Now, there are any number of these payment "solutions" out there that will both use P2PE in a way that qualifies you for the reduced-scope PCI compliance and will also do tokenization for you so that you keep the ability to charge a customer's card without ever having to actually store card information. Google or Bing will point you to any number of vendors who would be thrilled to tell you about their P2PE-compliant offerings. Whether those offerings are suitable to use with stripe--or, if they aren't, whether you want a reduced compliance burden so much that it's worth switching to a new processor--is something you'd have to think about.
- One thing its always good to remind anyone reading of: Storing debit card PIN numbers, data from the special authentication data track on the magnetic stipe, and/or that CVV/CAV string of 3-4 digits on the back of every card is always totally prohibited, even if encrypted, tokenized, whatever. Because those three things are items of information that a thief would need to have in order to produce a working counterfeit card, use a stolen card number online/over the phone, get money from an ATM, or do other fraudulent things. See page 15 of the linked-to PCI quick reference guide. Ironically, on the other hand a card's expiration date can be stored clear-text in perfect compliance with the rules.
God, PCI requirements can be stupid.
