Sign up Login

In-app Billing Types and Decision Tree

Follow

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              

1.png

DCB_in_app_blue_new.png

3.png

4.png

5.png

6.png

Connection Method  Data YES.png YES.png YES.png  YES.png NO.png NO.png
 WiFi YES.png NO.png YES.png  YES.png YES.png NO.png
 No Data NO.png NO.png NO.png  YES.png NO.png YES.png

Display Method

 Pre-built payment
platform
YES.png YES.png YES.png  YES.png YES.png YES.png
 Self-built payment platform NO.png YES.png YES.png  YES.png YES.png YES.png
Opt-in Method  MSISDN Forwarding YES.png YES.png NO.png  NO.png NO.png NO.png
 User exits App and sends SMS YES.png NO.png NO.png  NO.png NO.png NO.png
App controlled opt-in YES.png NO.png YES.png  YES.png YES.png YES.png
Billing Method Direct Operator Billing (DOB) YES.png YES.png NO.png  NO.png YES.png NO.png 
Premium SMS YES.png YES.png YES.png  YES.png YES.png YES.png

Confirmation Method

 

 

App looks for a
billing report
YES.png YES.png YES.png  NO.png NO.png NO.png
App can detect MT coming back NO.png NO.png NO.png  YES.png YES.png NO.png
App assumes billed
when MO is sent.
NO.png NO.png NO.png  NO.png NO.png YES.png

                                                                                         

 Key 

YES.png = Yes

NO.png = No

 

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. 

           edit_version.jpg

                 

          

 

Notable Country Specific In-app Billing Types

 

1.png

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.

 

DCB_in_app_blue_new.png


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. 

 

3.png

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. 

 

4.png

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. 

 

5.png

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. 

 

6.png

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. 

Was this article helpful?
0 out of 0 found this helpful

Comments

Powered by Zendesk