Evan Schuman's StorefrontBacktalk

The first is hardening the iPhone and iPad for use as in-store payment devices. Apple uses iPhones in its own stores, where salespeople can check customers out on the spot, and it’s a logical way for many retailers to use a tablet like the iPad. The problem: Handing a highly portable point-of-sale device to associates is a risky proposition. You don’t want the devices accidentally damaged; it could cause glitches that make the customer experience less pleasant or that ring up the wrong sale.

You also don’t want associates intentionally tampering with the devices with the intent of stealing payment-card information. It’s no real surprise that the PCI Council is skittish about certifying mobile devices and software. Securing payment-card hardware and software is hard enough when it’s installed in a store. But for associates, sneaking a mobile device home at night is relatively easy. And if an associate hacks the device by installing software to capture payment-card numbers, that blows away your PCI security.

But what if Apple extends its anti-tampering surveillance to include checking for software that shouldn’t be on the device? Then a hacked tablet or phone would become a brick as soon as the system spots the tampering. It wouldn’t just be a non-threat; it would also be a dead giveaway that the associate has done something very wrong with what’s supposed to be a secure payment device.

If retailer-owned mobile devices are a security challenge, customer-owned devices are much bigger targets. Smartphone users are walking around with powerful computers in their pockets—computers that face increasingly clever techniques for stealing payment-card information. Unfortunately, most smartphone users also don’t care much about security. They won’t worry about malware until it causes them real problems.

That’s the second place that, with a little stretching, Apple’s anti-tampering patent could make a difference in mobile payments. Imagine an iPhone that checked itself for malware and shut itself down if any was found. That would absolutely block any software designed to steal payment-card information or interfere with mobile-payment processes.

And if an infected smartphone suddenly became a brick, customers would have very good reason to deal promptly with a malware problem. After all, they won’t be making any phone calls—much less any mobile payments—until the problem is cleaned up.

That would make mobile payments a lot safer. It would also be a huge risk for Apple, which has already tried mightily (and with limited success) to keep its i-devices locked down. Adding a “feature” that threatens to shut down a phone at any moment would really raise the bar for Apple’s quality control, especially when it comes to software sold through iTunes.

Then again, it would set a new standard for mobile-payment security, too.