In-app Billing Types via Direct Operator Billing and Premium SMS
In-app billing also referred to as application billing, in-app payments or in-game payments, is the mechanism to bill within an application. In-app billing can be deployed for Android payments, Blackberry and Windows devices using our API. Apple's apps cannot be billed via these methods as they restrict to their iTunes billing platform.
Typically an in-app payment will allow service providers to monetise unlocking versions or features in their applications using mobile operator billing, be that via premium SMS or Direct Operator Billing. In the case of In-game billing this could mean making the game available to play initially, after a trial (freemium billing model), unlocking new levels or features, buying extra "lives" or to progress within the game.
Originally applications have been coded in Java and downloaded to the phones distributed via .JAD and .JAR files. More recently apps are increasingly using web technologies, such as HTML5 which means that the applications are served as mobile internet pages each time the application is opened, rather than a file downloaded to the handset.
The challenge with in-app billing is to make the payment as easy as possible for the user. The best user experience is for them to remain within the application or game, without having to exit or leave, and with a single click make a payment. On the lesser end of the usability spectrum, is for them to exit or minimise the application and view a confirmation code sent via SMS, and having to re-visit the application to commence.
The in-app billing market is evolving, and we are frequently seeing new methods being deployed. There is however, no standard way that operators are enabling in-app billing (some exceptions apply, e.g. in the UK, the Payforit Framework has been applied to in-app to provide a regulated method to deploy), so we have started to categorise based on typical models (payment flows). A country's operator service availability and regulatory restrictions dictate which can be used.
In-app Billing Type Descriptions
Prebuilt Compulsory payment screen embedded in app
A provided HTML screen is displayed within the App requiring a WiFi or Data connection to display. Typically the provided payment screen may have multiple billing features as the provider has built different functionality depending on the connection type.
|MSISDN detected app triggers billing||
The user's data connection identifies their MSISDN, this allows opt-in by agreeing to terms displayed within the application, the user is then billed by a direct operator billing connection without them exiting the App.
|App sends SMS, verified by delivery report||
The App sends an SMS on behalf of the user after they agree to terms within the App. Billing is verified by the App detecting the delivery report relating to the MT SMS message sent back to the handset without them exiting the App.
|App sends SMS, verified by MT received||
The App sends an SMS on behalf of the user after they agree to terms within the App. Billing is verified by the App detecting the MT SMS message sent back to the handset without them exiting the App. This doesn't work without a data connection or WiFi, as the app has no way to read the delivery report.
|MSISDN entered, PIN sent, app verifies and triggers billing||
Used as a fallback option where neither the MSISDN can be detected or an SMS can be sent by the App, the user is prompted to enter their MSISDN into the application, this triggers a standard rate MT to the handset which verifies the MSISDN, then a billing event can occur, either through Premium SMS or Direct Operator Billing.
|App sends SMS, verified by MO||
The App sends an SMS on behalf of the user after they agree to terms within the App. Without them exiting the App, billing is verified by the App detecting an MO SMS having been message sent from the handset, works best with MO billed countries.
In-app Billing Type Features
|In-app Billing Stage||
| Pre-built payment
|Self-built payment platform|
|Opt-in Method||MSISDN Forwarding|
|User exits App and sends SMS|
|App controlled opt-in|
|Billing Method||Direct Operator Billing (DOB)|
|App looks for a
|App can detect MT coming back|
|App assumes billed
when MO is sent.
In-app Billing Type Decision Tree
Each colour line represents a different In-app billing type. The line passes through the various methods that are possible to be deployed with that billing type. The methods are listed in order of how the application deploys the billing, e.g. first the application looks to see if it can connect to the internet, then it displays pricing instructions based on the best way to bill the user, next it would perform the billing and confirm billing before giving the user access.
Notable Country Specific In-app Billing Types
At present In the United Kingdom Payforit can be embedded into apps using HTML so long as there is a data or WiFi connection on the handset, this provides a good user experience on a data connection with one-click billing via MSISDN detection or WiFi via mobile number entry and PIN verification. However if there is no data connection the application would have to resort to a different in-app billing type.
There are upcoming requirements to become or use a 'Payforit Accredited Library'' for in-app purchases as will be mandated by the network operators and controlled by the 'Payforit Management Group'. It has not yet been disclosed if using the "Prebuilt payment screen embedded in-app" will still be acceptable after the upcoming mandate.
The 'Payforit Management Group' is made up of the principle operators along with some other individuals from the PRS industry. txtNation is a regular attendee to the group meetings and have the ability to advocate on decisions being made for the UK market. Just before Christmas 2012 the group began discussions on setting up documented requirements which outlines how in-app billing should be employed for the UK market. Rather than try to develop a Payforit solution for in-app they have decided it more feasible that they lay out a set of principles for how a payment library should work in the UK and then have a small number of companies put forward their solutions to be accredited.
- To get your own accreditation to offer your accredited Payforit Library to other merchants, at the moment the management group is still finalising the documentation. Once that is complete we will be able to give you detailed information on the requirements and also the process to getting your solution accredited.
- To use txtNation's accredited Library which has been built in the spirit of Payforit, on a trial basis before the official mandate, please contact your account manager.
Once the mandate is put in place then only accredited libraries will be able to use PSMS and Direct Operator Billing as a payment solution for in-app payments in the UK.
Please check back for more countries that support embedding a provided payment screen in-app, e.g. http://wiki.txtnation.com/wiki/txtNation_USA_Mobile_Billing.
See specific country entries on https://clients.txtnation.com/forums/97387-Regulations-Market-Data to see if MSISDN forwarding is permitted in a country. Should you wish to deploy MSISDN forwarding contact your account manager who can manage your approval.
See country entries on https://clients.txtnation.com/forums/97387-Regulations-Market-Data to see if in-app Billing (via App sending SMS on users behalf) is permitted in a country, and also if delivery reports are supported.
See country entries on https://clients.txtnation.com/forums/97387-Regulations-Market-Data to see if in-app Billing (via App sending SMS on users behalf) is permitted in a country.
See country entries on https://clients.txtnation.com/forums/97387-Regulations-Market-Data to see "Web (PIN) Opt-in" is permitted in a country, if you wish to deploy this contact your account manager who can manage your approval.
Working best in MO billed countries to avoid users getting content without being successfully billed via the return MT, also the country needs to allow the application to manage sending a message on the users behalf to avoid them having to manually create and send a text message. See https://clients.txtnation.com/forums/97387-Regulations-Market-Data for country specific data.