humblest_ever

The ideal process is the user would put his phone number into the web app, he would receive a text message, "text back <some PIN> to pay $X," and then payment would send a message to the web app server, maybe GETing something like Y.com/payment?from=5555555&secret_key=ZZZZZZZ

I'd like to get recommendations on who to use, and it's be great to know if anyone has used SMS payments in their own projects, and how it worked out.

IANAL, but I wanted to share a thought I had on subverting the subscription model for companies that cannot afford the 30% on subscriptions.

I am curious if it would be viable to give a proxy company access to your API, allowing them to offer your services to your users. They would be completely unable to offer subscriptions, they would have access to the functionality only. Any monetary exchange would be independent of them.

Then the app they create would have access to the paid sections of the API only for users that upgrade on the website. They cannot charge, so they cannot be obliged to make in-app payments available. They might even be able to redirect users to your website to pay without violating terms.

And it seems like Apple couldn't work around this without restricting a number of third-party apps.

The downside, of course, would be that you cannot put your own app in the app store.

While Apple is surely within its rights to take commissions from in-app sales, I suppose developers are also within their rights to find solutions like this (if it is viable).