Payforit Scheme Rules 4 1 4 Published 21november14

PAYFORIT SCHEME RULES 4.1.
4
Page 1 of 143
PAYFORIT SCHEME RULES VERSION 4.1.4

PUBLISHED: 21ST NOVEMBER 2014
Version Control: Date
Changes
4.1.1
4.1.2
4.1.3
25 Feb 14
1 May 14
21 August 14
See 4.1.2
See 4.1.3
Amendments to Enhanced P, in Section C Transaction Rules P97 & 98
Amendments to Enhanced , in Section D Style Rules, P105 & 106
21 Nov 14
4.1.4
(4.1.4 Assets)
26 Nov 14
New flow to replace Enchanced Single Click Enhanced purchase flow P47 50, Enhanced Purchase flow in
Section C Transaction Rules P101-102, Enhanced Purchase Flow in Section D Style Rules P112-113
New flow Double Opt-in flow P84-87, Double opt-in flow in Section C Transaction Rules P104-105, in Section
D Style Rules P114-115, Section E - Text Message Mandated Language P124-125
Amendment to Three Error Descriptions Section C Transaction Rules, Error Descriptions
(Asset files updated and posted to Payforit.org. All HTML codes will now be listed and hosted in the Asset File not in
this document)
PAYFORIT SCHEME RULES 4.1.4

Page 2 of 143
Contents
Page
CONTENTS
Introduction ........................................................................................................................................................................................................................................... 10
Document Construction ......................................................................................................................................................................................................................... 12
Payforit - A worked Example .................................................................................................................................................................................................................. 13
Consumer Experience Scenarios ............................................................................................................................................................................................................ 14
Roles and Responsibilities ...................................................................................................................................................................................................................... 15
API Responsibilities ............................................................................................................................................................................................................................. 16
Payment Library Responsibilities ........................................................................................................................................................................................................ 18
Merchant Responsibilities .................................................................................................................................................................................................................. 19
MNO Responsibilities.......................................................................................................................................................................................................................... 21
Payforit Management group .................................................................................................................................................................................................................. 22
Review of Payment Libraries .............................................................................................................................................................................................................. 22
Acceptance of Merchants using an Accredited Payment Library ........................................................................................................................................................ 23
Payforit Consumer Experience Flows ..................................................................................................................................................................................................... 24
Legend and Flow Diagrams ................................................................................................................................................................................................................. 26
Common Screen items ........................................................................................................................................................................................................................ 27
Mobile MSISDN Pass-Through ................................................................................................................................................................................................................ 33
Mobile MSISDN Pass-Through Flow diagram ...................................................................................................................................................................................... 33

Page 3 of 143
Mobile MSISDN Pass-Through Payment Screen ................................................................................................................................................................................. 34
Mobile Payforit Success Screen .......................................................................................................................................................................................................... 35
Mobile Payforit Failure Screen ............................................................................................................................................................................................................ 36
Mobile MSISDN through MT .................................................................................................................................................................................................................. 37
Mobile MSISDN through MT Flow ...................................................................................................................................................................................................... 37
Mobile MSISDN through MT screen ................................................................................................................................................................................................... 38
Mobile MSISDN through MT - Code Submit Screen ............................................................................................................................................................................ 39
Mobile MSISDN through MT Payment screen - Error Handling .......................................................................................................................................................... 40
Mobile MSISDN through MO .................................................................................................................................................................................................................. 41
Mobile MSISDN through MO Flow ...................................................................................................................................................................................................... 41
Mobile MSISDN through MO Screen .................................................................................................................................................................................................. 42
Mobile MSISDN through Hybrid ............................................................................................................................................................................................................. 43
Mobile MSISDN through Hybrid Flow ................................................................................................................................................................................................. 43
Mobile MSISDN through Hybrid Screen .............................................................................................................................................................................................. 44
Mobile Payforit Single Click .................................................................................................................................................................................................................... 45
Mobile Single Click Button .................................................................................................................................................................................................................. 46
Enhanced purchase flow ........................................................................................................................................................................................................................ 47
Enhanced Purchase Flow Entry ........................................................................................................................................................................................................... 48
Enhanced Purchase Flow Selection Screen ......................................................................................................................................................................................... 49

Page 4 of 143
Enhanced Purchase Flow Content Delivery Screen ............................................................................................................................................................................. 50
Embed Method for HTML5 Devices ........................................................................................................................................................................................................ 51
Embed MSISDN Pass-Through Flow Diagram...................................................................................................................................................................................... 53
Embed MSISDN Pass-Through Payment iFrame ................................................................................................................................................................................. 54
Embed Payforit Success iFrame .......................................................................................................................................................................................................... 55
Embed Payforit Failure iFrame ........................................................................................................................................................................................................... 56
Embed MSISDN through MT................................................................................................................................................................................................................... 57
Embed MSISDN through MT Flow ...................................................................................................................................................................................................... 57
Embed MSISDN through MT iFrame ................................................................................................................................................................................................... 58
Embed MSISDN through MO .................................................................................................................................................................................................................. 59
Embed MSISDN through MO iFrame ................................................................................................................................................................................................. 59
Embed MSISDN through MO iFrame .................................................................................................................................................................................................. 60
Embed MSISDN through Hybrid ............................................................................................................................................................................................................. 61
Embed MSISDN through Hybrid Flow ................................................................................................................................................................................................. 61
Embed MSISDN through Hybrid Screen .............................................................................................................................................................................................. 62
Embed Single Click.................................................................................................................................................................................................................................. 63
Embed Single Click Flow...................................................................................................................................................................................................................... 63
Embed Single Click Button .................................................................................................................................................................................................................. 64
Web Payforit Consumer Experience ....................................................................................................................................................................................................... 65

Page 5 of 143
Web MSISDN Pass-Through.................................................................................................................................................................................................................... 66
Web MSISDN Pass-Through Flow diagram.......................................................................................................................................................................................... 66
Web MSISDN Pass-Through Payment Screen ..................................................................................................................................................................................... 67
Web Payforit success Screen .............................................................................................................................................................................................................. 68
Web Payforit failure Screen ................................................................................................................................................................................................................ 69
Web MSISDN through MT ...................................................................................................................................................................................................................... 70
Web MSISDN through MT Flow .......................................................................................................................................................................................................... 70
Web MSISDN through MT screen ....................................................................................................................................................................................................... 71
Web MSISDN through MT - Code Submit Screen................................................................................................................................................................................ 72
Web MSISDN through MT Payment screen - Error Handling .............................................................................................................................................................. 73
Web MSISDN through MO ..................................................................................................................................................................................................................... 74
Web MSISDN through MO Flow ......................................................................................................................................................................................................... 74
Web MSISDN through MO Screen ...................................................................................................................................................................................................... 75
Web MSISDN through Hybrid ................................................................................................................................................................................................................. 76
Web MSISDN through Hybrid Flow ..................................................................................................................................................................................................... 76
Web MSISDN through Hybrid Screen.................................................................................................................................................................................................. 77
Web Payforit Single Click ........................................................................................................................................................................................................................ 78
Web Single Click Button ...................................................................................................................................................................................................................... 79
Gambling Purchase Flow ........................................................................................................................................................................................................................ 80

Page 6 of 143
Gambling purchase Flow diagram....................................................................................................................................................................................................... 80
Gambling Purchase flow Payment Screen .......................................................................................................................................................................................... 81
Gambling Purchase Success Screen .................................................................................................................................................................................................... 82
Gambling purchase Failure Screen...................................................................................................................................................................................................... 83
Double Opt-in flow ................................................................................................................................................................................................................................. 84
Double Opt-In Flow consumer Experience ......................................................................................................................................................................................... 85
Double Opt-in flow Selection Screen & Receipt .................................................................................................................................................................................. 86
Double opt-in flow Purchase Screen ................................................................................................................................................................................................... 87
Payforit Information Pages ..................................................................................................................................................................................................................... 88
About Payforit..................................................................................................................................................................................................................................... 89
Single Click Information ...................................................................................................................................................................................................................... 90
Need Help? ......................................................................................................................................................................................................................................... 90
Payforit In-App Charging ........................................................................................................................................................................................................................ 91
Introduction ........................................................................................................................................................................................................................................ 91
In-App Consumer Experience flow ...................................................................................................................................................................................................... 92
In-App User Verification ..................................................................................................................................................................................................................... 93
Section A - Payforit and Statutory Regulation ........................................................................................................................................................................................ 95
Section B - Breach of Payforit Scheme Rules .......................................................................................................................................................................................... 96
Revisions to Payforit ........................................................................................................................................................................................................................... 96

Page 7 of 143
Section C - Transaction Rules ................................................................................................................................................................................................................. 97
1.
Payforit Session .......................................................................................................................................................................................................................... 97
2.
Subscription and Service Transactions ....................................................................................................................................................................................... 97
3.
All MT and Hybrid based Consumer Experience Flows ............................................................................................................................................................... 98
4.
MT- MO Hybrid Consumer Experience Flows ............................................................................................................................................................................. 98
5.
MO Consumer Experience Flows ................................................................................................................................................................................................ 99
6.
Payforit Single Click .................................................................................................................................................................................................................... 99
7.
Enhanced Purchase flow........................................................................................................................................................................................................... 101
8.
Gambling Purchase Flow .......................................................................................................................................................................................................... 103
9.
Double opt-in flow .................................................................................................................................................................................................................... 104
10.
Error Descriptions ................................................................................................................................................................................................................. 106
11.
Text Receipts ........................................................................................................................................................................................................................ 106
12.
MSISDN ................................................................................................................................................................................................................................. 107
13.
Alternate Mobile Processing ............................................................................................................................................................................................. 107
14.
Screen Display Processing..................................................................................................................................................................................................... 108
15.
Payment Failure .................................................................................................................................................................................................................... 109
Section D - Style Rules .......................................................................................................................................................................................................................... 110

1.
Pricing Notification Field........................................................................................................................................................................................................... 110
2.
Merchant Name ....................................................................................................................................................................................................................... 111

Page 8 of 143
3.
Price .......................................................................................................................................................................................................................................... 111
4.
Payment Received Notification ................................................................................................................................................................................................ 111
5.
Screens, Pages, iFrames, and Buttons ...................................................................................................................................................................................... 111
6.
Embed Method for HTML5 Payments ...................................................................................................................................................................................... 112
7.
Enhanced Purchase Flow .......................................................................................................................................................................................................... 112
8.
Double Opt-In Flow .................................................................................................................................................................................................................. 114
9.
Payforit Logo ............................................................................................................................................................................................................................ 115
10.
MNO and API Logo Placement .............................................................................................................................................................................................. 116
11.
Merchant Logos, Slogans, and Designs ................................................................................................................................................................................. 117
12.
Payforit Single Click Logo and Button ................................................................................................................................................................................... 117
Section E - Text Message Mandated Language .................................................................................................................................................................................... 118

Section F - Audit Log Requirements ..................................................................................................................................................................................................... 126
Section G Customer Service Requirements ....................................................................................................................................................................................... 127
Section H Payforit Management Group ............................................................................................................................................................................................. 128
Payforit Variation .............................................................................................................................................................................................................................. 129
How to apply for Payforit Variation at a PFI MG meeting ................................................................................................................................................................. 130
Providing supporting written proposals............................................................................................................................................................................................ 130
Assessment criteria ........................................................................................................................................................................................................................... 131
Approval of Payforit Variations ......................................................................................................................................................................................................... 132

Page 9 of 143
PFI MG approval process for Payforit Variation ................................................................................................................................................................................ 133
Network Operator implementation of the Payforit Variation........................................................................................................................................................... 134
Obligations on APIs following Payforit Variation .............................................................................................................................................................................. 134
Monitoring ........................................................................................................................................................................................................................................ 134
Withdrawal of Payforit Variation ...................................................................................................................................................................................................... 135
Other ways to communicate with the PFI MG .................................................................................................................................................................................. 135
Section I - Payment Libraries Review and Acceptance Criteria ............................................................................................................................................................. 136
Relationship between Parties ........................................................................................................................................................................................................... 136
Payment Library Requirements ........................................................................................................................................................................................................ 137
Prevention of Reverse Engineering ................................................................................................................................................................................................... 137
Encryption of traffic to prevent interception of the Data ................................................................................................................................................................. 138
Authentication of traffic to protect Integrity of the Data ................................................................................................................................................................. 138
Service Review and Acceptance ........................................................................................................................................................................................................ 139
Acceptance of Payment Libraries...................................................................................................................................................................................................... 139
Acceptance of Merchants using an Independent Payment Library .................................................................................................................................................. 140
Acceptance of Merchants using own Payment Library ..................................................................................................................................................................... 141
Acceptance of an API using own Payment Library ............................................................................................................................................................................ 142

Page 10 of 143
INTRODUCTION
Payforit provides a consistent series of payment screens that ensure a mobile consumer is able to purchase digital products and services online and charge the
cost to their mobile phone bill or prepaid balance. Payforit ensures that all services deliver clear pricing information, easy access to terms and conditions and
Merchant contact information before and after the sale.
Payforit is NOT a company, it is a mobile Consumer Experience Scheme and trust mark supported by the UK Mobile micropayments industry and was first
announced in March 2006. The Payforit Scheme was developed by the UK mobile network operators (MNOs), in conjunction with the industry trade association
AIME (www.aimelink.org) and the regulators, Ofcom (www.ofcom.org) and the agent of the regulator, PhonepayPlus (www.phonepayplus.org.uk) (PPP), in order
to promote a trusted and consistent means of paying for digital goods and services and charging that payment to a mobile monthly account or prepaid balance.
Consumers purchasing digital products and services through providers using the Payforit Scheme can do so with confidence when making one-off payments,
setting up subscription services or making charitable donations. In 2013 PhonepayPlus (PPP) endorsed the Payforit Scheme stating that it promoted consumer
clarity and protection whilst purchasing services via their mobile. From a Merchant perspective if the Merchant followed the Scheme they would adhere to the
PhonepayPlus 12th code of practice concerning presentation of clear pricing. Please refer to PhonepayPlus statement re: Payforit June 2013.
With Payforit, consumers do not need a credit /debit card or online account to use the service. They also dont need to sign up or pre- register any details. All they
need is their mobile device.
The MNOs authorise a small number of commercial entities to act as Accredited Payment Intermediaries (APIs). These APIs perform under individual
contractual conditions to the mobile networks and are monitored by each network under a set of objective criteria designed to ensure their suitability to operate
the Payforit Scheme. APIs must ensure that consumer transactions are managed and processed in accordance with the Payforit Scheme Rules and other
appropriate laws and regulations.
APIs contract with providers of online digital products and services to enable the mobile payment part of the consumers purchasing journey when they are
accessing internet services. For the Payforit Scheme, these providers are known as Merchants. The Payforit Scheme as applied to the transaction element of the
consumer experience with the Merchant ensures that it is consistent, secure, transparent and user-friendly at all times.
For reference, PhonepayPlus define APIs as Level 1 (L1) and Merchants as Level 2 (L2). Please refer to PhonepayPlus 12th Code of Practice for full definition.
The Payforit Scheme applies to all services that are discovered and consumed on the internet and charged to the mobile users account regardless of the device the
consumer is using to access the service, be it a conventional mobile, a Smartphone, a tablet or computer and whether or not that device is connected to the
internet via a mobile network, Wi-Fi facility, broadband or other means.

Page 11 of 143
Payforit delivers these principles:
Full pricing transparency in a clear way prior to any financial commitment

Full detail of any service terms that are likely to influence purchasing decisions
Full auditable opt-in by the consumer to the charges
Inability for any party other than the API to apply charges
Protection of consumers contact details
Auditable and informed opt-in to future marketing by the Merchant
Easy to access and read, detailed terms and conditions
Electronic receipts, subscription notifications and spend reminders
Cessation of subscription services through an easy to use method
Full consumer support for post-transaction enquiries
Full audit trails for a minimum period of six months
For Merchants, Payforit delivers:

Easy integration to the payment process
Compliance with the Pricing principals stated in the PPP 12th Code of Practice
Payforit is not designed to deliver:
Full compliance with UK legal and regulatory requirements (as highlighted by PPP statement on Payforit June 2013)
Prior permission for certain services that are required under the PPP Code
Complete requirements of due diligence and risk control as defined by PPP
Advertising Codes compliance and protection from any misleading behaviour from affiliates
Age verification for adult services
Compliance with Payment Services Directives or eMoney Directives
Individual network approval process. Introduction of a payment flow still requires a Merchant/ API to follow the individual network approval process for
services going live

Page 12 of 143
DOCUMENT CONSTRUCTION
The Scheme Rules document is primarily aimed at APIs and contains detailed information on the application of the Payforit consumer experience screens, layouts,
wording and other rules.
Merchants will benefit from familiarisation with the Payforit Scheme and a section has been included specifically for Merchants. When designing a Merchant
Checkout Flow it is beneficial to understand the different environments that the consumer may be in as well as the different devices they could use. This will help
maximise checkout success.
Hyperlinks are contained in this document to enable a quick jump to alternative pages or references and therefore, this document is best utilised electronically.
On each page with a title, a button will provide a jump back to the contents page.
Click to go
back to
Contents
Page
Cross references and hyperlinks are highlighted to show a clickable part of the text. These links will lead to the relevant part of the document (if the PDF reader
supports hyperlinks) or to an external web site.

Page 13 of 143
Click to go
back to
Contents
Page
PAYFORIT - A WORKED EXAMPLE

This description of how Payforit works is one of a range of possible payment scenarios, chosen
for simplicity.
When the consumer is browsing the internet with any device and wishes to buy a digital
product or service from a Merchant, for example a music track, the Merchant screen will have
a button or link that allows the consumer to make their purchase selection.
Once the consumer clicks on the link, they are forwarded to the Payforit API who will display
relevant details about the product being purchased including the price and a Buy Now
button.
At the same time, the mobile number of the consumer is transferred to the API by the
consumers mobile network.
Once the consumer clicks on the Buy Now button, the API applies the charge to the
consumers mobile network.
If the network accepts and confirms the charge, the API sends a text receipt to the consumer
and passes the consumer back to the Merchant for delivery of the purchased product.
The Merchant then supplies the digital product or service to the consumer. The Merchant is
responsible for post-sale Customer Service. All initial enquiries to MNOs will be directed to the
Merchant (or their nominated Customer Service agent) for support.
If the MNO does not accept the charge for any reason the consumer is presented with a
payment failure screen.

Page 14 of 143
Click to go
back to
Contents
Page
CONSUMER EXPERIENCE SCENARIOS

The above example details just one possible scenario of a Payforit Consumer Experience.
The full range of Payforit Consumer Experience Flows detailed later in this document are
designed to suit multiple situations where a consumer will make online purchases using their
mobile account:
Sample Payforit Consumer Experience Flows
One-off payments; (Buy now)

Subscription set up (recurring charges), ongoing charges, notification and management;
(Subscribe now)
Donations to charities; (Donate now)
Repeat purchase from the same Merchant; (Payforit Single Click button)
Purchases within a Smartphone application; (In-App charge)
Purchases within an HTML5 web application; (Embed method)
HTML5 supporting devices
The Payforit Consumer Experience Flows also cater for access by several devices over
different network environments:
Mobile devices on either mobile network or Wi-Fi networks
Tablets and computers on mobile and Wi-Fi/broadband networks
Mobile devices
See Payforit Consumer Experience Flows for full information.
Single Click Button

devices
Web browsers

Page 15 of 143
Click to go
back to
Contents
Page
ROLES AND RESPONSIBILITIES

In a consumer online purchasing scenario, several parties are responsible for the consumer
journey. The consumer may encounter an advert or promotion for a digital product and be
directed to the Merchant web site, mobile site or application. The PPP 12th Code of Practice
delivers the principals concerning fair promotion of services, which are therefore NOT covered
by this Scheme. The Payforit Scheme details the relationship that each party has with the
consumer and with each other.
The Merchant funds the advertising or promotion that brings the consumer to their service
and supplies the shopping experience for the consumer. The Merchant engages with the API to
supply the checkout and charging of the consumer.
The Payment Library specifically for In-App charging provides the software library, which
manages the In-App pricing presentation, payment flow and other factors that can affect a
consumers decision to pay and gains their acceptance of the charge. This role may be also
played by the API.
The API presents the Merchant pricing, terms of service and other relevant information to the
consumer and facilitates the charges on behalf of the Merchant, only after authorisation is
gained from the consumer via the Payforit approved Consumer Experience Flows. The charge is
applied to the mobile network operator (MNO) billing capabilities to the consumers mobile bill
or prepaid balance. The API, in some cases also provides post-sale Customer Service for
consumers.
The MNO is responsible for the consumers mobile account, provides the identity of the
consumers mobile number to the API during the transaction (where technically possible) and
takes final responsibility for Customer Services when the consumer is unable to resolve issues
satisfactorily with either the Merchant or the API who is acting on behalf of the Merchant.
All parties are responsible for compliance with all relevant laws and regulations covering
operation in the United Kingdom and in Europe.

Page 16 of 143
Click to go
back to
Contents
Page
API RESPONSIBILITIES
The API role is pivotal to the successful operation of a mobile micropayment service using Payforit.
On one side is the APIs customer, the Merchant, who will interface with the APIs technical system, handing over the consumer from the Merchant screens to the
API screens and back again with the relevant background transfer of information related to the purchase, billing success/failure and consumers opt-in/opt-out to
Merchant marketing.
On the other side of the transaction is the MNO (or MVNO), and more importantly, the billing interfaces and customer accounts, which are debited by the API (to
the extent permitted by individual MNO contracts) to enable the billing and payment by the consumer.
Between them is the consumer who is making the transaction using the Payforit Consumer Experience Flows and who will accept or cancel the purchase.
Due Diligence and Risk Control (DDRC)

It is the APIs responsibility to carry out due diligence on the Merchant, their services and the clarity of information available to the consumer prior to the Payforit
screen. In the interests of consumer protection it is vital that APIs maintain on-going risk management and risk controls to ensure that approved services do not
change. Please refer to PPP Guidance on DDRC. The API will also be held responsible for the manner in which Affiliate Marketing traffic is delivered.
In respect of the Gambling Purchase Flow the API must procure, in advance, and be able to produce on request by any Payforit Management Group member
Mobile Network current documentation and licencing outlined in Section A - Payforit and Statutory Regulation The API must ensure that any licences held by the
merchant remain current and in effect.
When the Payforit information becomes part of the Merchants environment with Embed Method and Single Click, Merchants take full responsibility that their
environment does not obscure, mask, distract or otherwise cause the consumer to be unaware or be misled about pricing and other key information that would
affect their decision to purchase. APIs must deploy ongoing risk assessment and controls to ensure that their Merchants continue to comply with this
requirement.
Subscription Management
The API is responsible for all aspects of subscription management including the initiation and reminder text messages and the route for consumers to cancel the
subscription.
Success Tracking

Page 17 of 143
APIs are expected to monitor the performance of the Merchant payment success ratios. A high proportion of checkout abandonment indicates a service where the
Payforit screens are providing checkout shock for consumers and requires investigation. A high transaction success is positive and can be gained by the
Merchant using usability techniques that the API will be experienced in and by providing clear pricing to consumers early during their purchase journey. A highly
successful service could, however, indicate a separate issue that should be investigated.
Data Logging
APIs are expected to maintain readily available logs for the consumer purchase to handle enquiries and disputes instigated by the consumer and/or the MNO or
PPP. Logs of transactions should show the information that is laid out in Section F - Audit Log Requirements in this document and be readily available for the party
who is handling the consumer enquiry.
Customer Service
Customer service numbers must be available to the consumer prior to purchase, as per PPP 12th code (updated 13th June 2014). Post transaction Customer Service
is primarily the responsibility of the Merchant as in all other forms of digital purchasing, but an API can offer this facility as a service to their Merchants. Customer
Service obligations are set out in Section G Customer Service Requirements.
Refund Processing
If the consumers MNO supports a refund or credit facility, this should be used to provide refunds if the consumer has a legitimate or accepted reason for
requesting one (determined individually by each MNO). Merchants must offer a refund or credit facility in line with their legal obligations (including distance
selling regulations) and consumers must receive refunds without unnecessary hurdles.
Text Receipts
APIs are also responsible for sending text receipts to consumers for every purchase based on the rules in this document. APIs must make the necessary
arrangements for devices that cannot receive SMS texts as outlined in Section E - Text Message Mandated Language

Page 18 of 143
Click to go
back to
Contents
Page
PAYMENT LIBRARY RESPONSIBILITIES

The role of the Payment Library is essential to create the secure software and server environment for consumers purchasing products and services within
applications.
The Payment Library provider supplies systems and environment to secure the integrity of the Payment Library including:
Prevention of reverse engineering of the library by third parties using second generation obfuscation software
Encryption of traffic to prevent interception of the Data
Authentication of traffic to protect the integrity of the Data
The Payment Library provider works hand in hand with the API to ensure that the presentation of information to the consumer inside the App cannot be tampered
with and provides the Consumer Experience Flows, while the API provides the charging interfaces, text receipting, contract management and liaison with the
Payforit Management Group (PFI MG).

Page 19 of 143
Click to go
back to
Contents
Page
MERCHANT RESPONSIBILITIES
Payforit has proved to be a very successful and trouble free environment for Merchants and is an important part of the Merchants consumer relations strategy to
ensure that the purchase part of the consumer journey is easy, informative and robust.
Customer Experience
Merchants must deliver to a consumer (by MSISDN) a consistent user experience for a single service across all APIs. Each service must have the APIs due diligence
and risk control process applied before going live.
Technical quality
Merchants need to ensure that they work together with the API to ensure that the Consumer Experience Flow is logical, consistent and that the user is able to
receive the product or service that they have purchased. Merchants are reminded that their sites and the sites that lead users to the Merchants sites are subject
to advertising standards (such as the CAP Code).
Pricing clarity
The Payforit Scheme guarantees pricing clarity to the consumer at the payment part of the consumer journey on the Merchant's website, nevertheless it is the
responsibility of the Merchant to ensure they are consistent and transparent with their pricing so that the consumer is fully informed and that there are no
surprises when they reach the Payforit payment screens. Consumers should be aware prior to the Payforit screens what the product is that they are purchasing,
what the price is going to be and how they can receive the product after purchase.
Promotions that lead users to the Merchant site should not promote anything that later turns out to be false, such as free content when there is none.
Users returning from Payment pages

Merchants will need to cater for consumers returning to their site, having pressed cancel and to deal with the possible reasons for their return. This could be
from not understanding the reasons for a request for payment, to looking for a lower cost option.
Merchants should ensure that consumers receive the relevant digital products or service in line with their legal rights. This part of the payment flow must be
reliable. The text receipt sent to the consumer after payment may provide a link to return to the Merchant if the consumer has lost the browsing session.

Page 20 of 143
Customer Service
Customer Service numbers must be available to the consumer prior to purchase, as per PPP 12th code (updated 13th June 2014). Post transaction Customer Service
is primarily the responsibility of the Merchant as in all other forms of digital purchasing, but an API can offer this facility as a service to their Merchants. Customer
Service obligations are set out in Section G Customer Service Requirements.
Key Terms of Service

The Payforit screens provide a link to a page which must contain the Payforit and Merchants terms and conditions relating to the purchase and covering any
legislative or regulatory requirements, including the use and disclosure of consumer information.
It is the Merchants responsibility to ensure that the terms declared to the consumer are up to date, legible, and accurate and contain all the necessary
information required by regulation, law and by the consumer in order to complete their transaction.
As a recommendation, services with complex terms such as competitions, should have a summary of the key factors that would assist a purchasing decision, such
as minimum cost of entry, draw dates, winner selection criteria etc.
Embed Method and Single Click

The Payforit Scheme places the responsibility on the API to provide the required information to the consumer before they make the decision to purchase and the
API, having served the Payforit screens, is confident that this information is available for the consumer or has been displayed to the consumer.
When using Embed Method and Single Click, the Payforit information becomes part of the Merchants environment. Merchants are to take full responsibility to
ensure that their environment does not obscure, mask, distract or otherwise cause the consumer to be unaware or be misled about pricing and other key
information that would affect their decision to purchase. API should deploy ongoing risk assessment and controls to ensure that their Merchants continue to
comply with this requirement.
In all instances the Merchant must ensure that they provide a consumer contact number. See Section G Customer Service Requirements.

Page 21 of 143
Click to go
back to
Contents
Page
MNO RESPONSIBILITIES
The MNOs developed the Payforit Scheme Rules in conjunction with the industry and in co-operation with PPP with the objective of managing consumer
experience when purchasing services online, paid for using the pre-pay balance or monthly bill.
The MNOs:
Ensure that the Payforit Scheme takes into consideration market demands and changes in technology to ensure the relevance of the Scheme
Work with APIs to manage on-going requests for additions and amendments to the existing Scheme Rules as defined in Section H Payforit Management
Group.
Ensure that the Scheme Rules continue to protect consumers, taking into account latest scams by unscrupulous providers, working in conjunction with PPP to
close down scams
The MNOs are responsible for the collective group known as the Payforit Management Group, who oversee this process.

Page 22 of 143
Click to go
back to
Contents
Page
PAYFORIT MANAGEMENT GROUP

Representatives from each MNO work to protect consumers and ensure the Scheme Rules develop to accommodate new technologies and threats. This group
meets monthly and APIs can request additions and amendments to the Scheme Rules. Each meeting is chaired by an MNO and the independently employed
secretariat is charged with taking minutes and communicating decisions. The meeting is held in accordance with UK and EU competition law requirements.
The Scheme is on a continuous evolution to cater for changes in device technologies, services, consumer interaction and regulation. The Payforit Management
Group (PFI MG) consists of representatives from each MNO and contact details are available on Payforit.org.
APIs and their Merchants are encouraged to contact the PFI MG for details on how to participate and to provide comments on the Scheme. Details of how to
interact with the PFI MG are included in Section H Payforit Management Group.
REVIEW OF PAYMENT LIBRARIES

Within the In-App billing flow a third party secure library is required to host the payment screens as this is not possible by any other mechanism. The PFI MG will
review the proposed Payment Library flow and operation with both the API and the Payment Library Provider (see Section I - Payment Libraries Review and
Acceptance Criteria for detailed requirements) and will either accept, or provide the suggested changes and improvements to accept the library based on the fit
with the Payforit principles and Required Payment Flow. See Payforit In-App Charging.
This review will also include a security audit of the Payment Library Provider as well as the Payment Library operation.
The Payment Library Provider is then responsible for notifying the API and PFI MG of any changes to the library that would change the proposed library flow and
operation.
Once accepted with one API, a Payment Library is then accepted for use with other APIs, as long as the Payment Library user experience and functionality are
unchanged.
If the Payment Library is changed significantly between versions, then a new review will be required.
These changes would include:
Changes to the UK payment flow or user verification methods used
Technology change, i.e. to support an additional native platform
Major release of the library

Page 23 of 143
There are three operational models that the PFI MG will consider for In-App charging under the Payforit brand:
1. Independent Payment Library Company: This Company, once accepted will be able to offer Payment Library services to multiple Merchants and provide its
charging facilities through different APIs without any further acceptance needed from the PFI MG. It will be required to seek approval from the API for
each Merchant to go live.
2. Payment Library Company and Merchant are the same entity: These Merchants are expected to be potentially FCA registered and have an account
relationship with the purchasing consumer.
3. Payment Library Company and API are same entity: Any API can seek PFI MG acceptance for its Payment Library and once this is gained, can offer In-App
charging services to its Merchants.
Engagement with PFI MG is required using the standard template if a Merchant does not follow the above requirements.
ACCEPTANCE OF MERCHANTS USING AN ACCREDITED PAYMENT LIBRARY

Once a Payment Library is accepted, then it can be used to provide In-App charging as per the conditions above, without further acceptance by the PFI MG.
However the API will be required to approve the Merchant and service before it can be launched. This will include a risk assessment by the API including Merchant
checks against the PPP register and Companies House.
For further details see Section I - Payment Libraries Review and Acceptance Criteria.

Page 24 of 143
Click to go
back to
Contents
Page
PAYFORIT CONSUMER EXPERIENCE FLOWS

This section details every variation of the Payforit Consumer Experience Flows defined for the Payforit Scheme.
The flows must be presented by the API to the consumer when the consumer is performing a purchase from the Merchant.
Under the Payforit Scheme, elements of screen presentation and consumer interfaces such as buttons and clickable links are repeated across different flows.
These are detailed initially but not detailed in each flow to avoid duplication and complexity. Please cross refer to the Common Screen items section for each
Payforit Consumer Experience Flow.
The consumer is charged via their mobile account using the mobile number (MSISDN) as the billing reference. When the device is on the mobile network, in most
instances, the MSISDN is transferred to the API by the MNO, while the consumer is accessing the APIs Payforit pages. In some cases, the APIs implement a facility
to acquire the MSISDN from the MNO prior to a Payforit transaction to establish if the consumer is returning to a site from which they made a previous purchase.
Where the consumer is presented with a Payforit page outside of the mobile network (e.g. Wi-Fi) or they are accessing the service from another device (tablet or
computer), it is necessary to gain the MSISDN directly from the consumer and then verify if they have control over the mobile device for which the MSISDN is
registered to.
The Consumer Experience Flows are therefore:
1. Mobile MISISDN Pass Through Flow: Payforit for display on a mobile device with the MSISDN automatically transferred by the network.
2. Mobile MSISDN through MT flow: Payforit for display on a mobile device with the MSISDN entered by the consumer and verified by sending an SMS with a
unique code to the MSISDN which has to be entered into the payment page.
3. Mobile MSISDN through MO flow: Payforit for display on a mobile device with the MSISDN gained from the consumer by the consumer sending a code to a
number given on screen via text.
4. Mobile MSISDN through Hybrid flow: Payforit for display on a mobile device with the MSISDN entered by the consumer and verified by sending a text message
to the MSISDN to which the consumer must reply.
5. Mobile Payforit Single Click flow: with the MSISDN gained through one of the methods detailed above and where the consumer opts into Single Click and
therefore making subsequent purchases via an API served payment button inside the Merchant Screen.
6. Enhanced Purchase Flow: Payforit for display on a mobile device with MSISDN Pass-Through and where Merchant pages and Payment Buttons are presented by
the API on behalf of the Merchant.

Page 25 of 143
7. Embed Method for HTML5 Devices flow: Payforit for display on a device that supports HTML5 with the MSISDN automatically transferred from network.
8. Embed MSISDN through MT flow: Payforit for display on a device that supports HTML5 with the MSISDN gained from the user and verified by sending a
Payment Code to the MSISDN which has to be entered into the payment page.
9. Embed MSISDN through MO flow: Payforit for display on a device that supports HTML5 with the MSISDN gained from the consumer by the consumer sending a
specially coded text message.
10. Embed MSISDN through Hybrid flow: Payforit for display on a device that supports HTML5 with the MSISDN gained from the consumer and verified by
sending a text message to the MSISDN to which the consumer must reply.
11. Embed Single Click flow: with the MSISDN gained through one of the methods detailed above and where the consumer opts into Single Click and therefore
making subsequent purchases via an API served payment button inside the Merchant Screen.
12. Web MSISDN Pass-Through flow: Payforit for display on a device with the MSISDN automatically transferred from the mobile network.
13. Web MSISDN through MT flow: Payforit for display on a computer, tablet or other landscape formatted device with the MSISDN gained from the user and
verified by sending a Payment Code to the MSISDN which has to be entered into the payment page.
14. Web MSISDN through MO flow: Payforit for display on a device with the MSISDN gained from the consumer by the consumer sending a specially coded text
message.
15. Web MSISDN through Hybrid flow: Payforit for display on a computer, tablet or other landscape formatted device with the MSISDN gained from the
consumer and verified by sending a text message to the MSISDN to which the consumer must reply.
16. Web Payforit Single Click flow: Payforit for display on a computer, tablet or other landscape formatted device with the MSISDN gained through one of the
methods detailed above and where the consumer opts into making subsequent purchases via an API served payment button inside the Merchant Screens.
17. Gambling Purchase Flow: Payforit for display on a mobile device with the MSISDN automatically transferred by the network for gambling purchases.
18. Double Opt-in flow Payforit for time-based access to services or promotions, or purchase virtual goods or service credits which can be offered by the
merchant using a one time or recurring payment mechanic
19. Payforit In-App Charging: Payforit for display to consumers during a purchase within an Application (App) running on a device that supports Apps. This
capability is less defined in terms of display but is run through an accepted Payment Library Company working in conjunction with an API.

Page 26 of 143
Click to go
back to
Contents
Page
LEGEND AND FLOW DIAGRAMS

For each mobile option, the Scheme Rules include individual Consumer Experience Flow
graphics, with colour coding and labels as defined in the legend on this page.
APIs must follow the flow graphics to establish the Merchant screens, API screens, buttons or
information to be presented to the consumer during the Payforit transaction.
Each button, hyperlink and consumer entry field is described in the Common Screen items
section.
The narrative alongside the Payforit screen images for each flow discusses the circumstances
under which each flow should be used and the expectations to be met.
All Payforit screens are available as HTML assets from the API section of Payforit.org (login
required).
In all Payforit flows, Payforit Information (About Payforit) is available when the Payforit logo
is clicked or the hyperlinked Payforit or Payforit terms are clicked as detailed.
In all Payforit flows, the Merchant terms are available when the hyperlinked words Merchant
Terms are clicked by the consumer. The Merchant terms must be up to date, clear and
meaningful. It is recommended that Merchant terms contain a Key Facts section, which
contains all the relevant information, in plain English, that could affect a consumers decision
to purchase.

Page 27 of 143
Click to go
back to
Contents
Page
COMMON SCREEN ITEMS

Across all the Payforit Consumer Experience Flows, there are screen display elements,
clickable links, buttons and boxes which are under the control of the API or require an
input from the consumer and are common across multiple flows. To avoid repetition
throughout this document, the common API controlled items and consumer input are
detailed here.
Sample Mobile Payment Screen
Payforit Logo
This section of the document should be referred to when implementing any of the
Payforit Consumer Experience Flows. Links from individual flows back to this page are
available inside the document to make document navigation easier.
The screen sample on this page shows a mobile screen with the MSISDN passed to the
API by the mobile network.
1. Payforit Logo (Mandated): When clicked by the consumer, the API will present the
About Payforit screen. See About Payforit.
2. Merchant Detail (Mandated): This screen section can carry either the Merchant
Brand (as in this example) or the Merchant Name. The Merchant name must always
appear on Payforit screens and must be the name of the Merchant that is
recognisable from the consumer journey to this screen. See Section D - Style Rules
for maximum size of brand presentation. Brand must be consistent with prior pages
served by Merchant.
3. Pricing Notification (Mandated): Uses Scheme Rules adjectives (see Section D - Style
Rules for mandated language) such as Buy, Subscribe, Deposit, Donate
together with the Merchant product name (that is consistent with the product the
consumer elected to purchase from the Merchant) and the price displayed in or p
(pence) to make up the Pricing Notification section.
4. Charge Notification (Optional): This section advises the consumer that their mobile
account will be charged and shows the last 4 digits of their mobile number. It is only
required on MSISDN Pass-Through Flows.
Merchant Detail
Pricing Notification
Charge notification
Call to Action
Button
Alternate Mobile
Link

Page 28 of 143
5. Call to Action button (Mandated): Dependant on the Consumer Experience Flow it can
read Continue, Buy Now, Donate Now, Deposit Now or Subscribe Now.
Button colour must meet requirements in Section D - Style Rules.
6. Alternate Mobile (Optional): Allows the consumer to bill their purchase to another
MSISDN, which has to be verified using the Mobile MSISDN through MT flow.
Product or service is delivered to original device.
Payforit Logo
Merchant Detail
Charge notification
Call to Action
Button
Alternate Mobile
Link

Page 29 of 143
The screen sample on this page shows the screen elements when the consumers
MSISDN is required and also shows the Merchant name instead of brand
1. Merchant Name (Mandated): Must be the name of the Merchant that is
recognisable from the consumer journey.
2. MSISDN Entry box for Mobile MSISDN through MT flow. Consumer will enter their
number for verification. Used when MSISDN is not available from mobile network.
Must be able to take +44, 44 and 07 numbers. A dropbox for consumers to select
their own network can be provided.
3.
Dont know your mobile number? link (Optional): This is potentially used by the
consumer when they are using a broadband device and they do not know its mobile
number. This clickable link switches the Consumer Experience Flow from Mobile
MSISDN through MT flow to Mobile MSISDN through MO flow.
4. Cancel Purchase Link (Mandatory): Takes the consumer back to the Merchant
Screen. The Merchant must handle the consumer return elegantly as the return
could be for multiple reasons e.g. price was not as expected, subscription was
unexpected, product details were unexpected or that the consumer has changed
their mind.
5. Help Section (Mandatory): Must contain the Merchant or API support details. The
phone number can use click to call Smartphone function. The email address can
use click to email" Smartphone function. The Merchant link will open a Merchant
(or API) served page with Merchant terms for the purchase. The Payforit link will
open an API served Payforit Information Page (see About Payforit).
Merchant Name
MSISDN Entry
Dont know
number Link
Cancel Purchase
Link
Help Section

Page 30 of 143
The screen sample on this page shows the screen elements when a payment has
been successfully applied to the consumers mobile network.
Sample Success Screen
1. Payment Received Notification (Mandatory): Advises the consumer the amount

that they have paid from their mobile account and must match the price shown on
previous screens.
2.
Enable Payforit Single Click (Optional): This consumer selection is optional for
the Merchant and allows the consumer to conduct future transactions with the
Merchant by clicking on API served Payforit buttons on the Merchant site.
Payment Received
Notification
3. Payforit Single Click Link (Optional): The link will open an API served, Payforit
Single Click Information Page (see Single Click Information).
4. Marketing OptIn (Optional): Send offers for similar products and services to my
mobile. This consumer selection is optional for the Merchant and allows the
Merchant to conduct marketing to the consumer directly or via the API in the
future. See Section E - Text Message Mandated Language for marketing rules.
Enable Single Click

Marketing Opt In

Page 31 of 143
The screen sample on this page (Web flow) shows the screen elements when an
error has occurred.
Sample Error Screen
1. Error reason (Mandatory): API will present the reason for the error using the Error
Reasons guide in Section C - Transaction Rules.
2. Retry button (Mandatory): This Call to Action button will return the consumer to
the Payment page for the consumer to make the choice of retrying the transaction
or cancelling the transaction and returning to the Merchant.
3. Error Message (Optional): This message is used to inform the consumer of any
other options that the API can offer (such as entering an alternative number).
Error reason
Retry Button
Error Message

Page 32 of 143
Click to go
back to
Contents
Page
PAYFORIT CONSUMER EXPERIENCE FLOWS

The following sections detail Payforit Consumer Experience Flows across various screen formats that can be used by consumers and includes Mobile (portrait
format), Web (landscape format), Embed (iFrame) for HTML5 supporting devices and Enhanced Purchase Flow. Payforit In-App Charging is detailed in its own
section. The HTML and CSS files for generating the majority of the screens detailed in this document are available in the Payforit Assets file located behind the login on Payforit.org . These files are provided for guidance and illustrative purposes only and will need to be re-coded appropriately inside the APIs Payforit software
suite to render correctly on all devices.

Page 33 of 143
Click to go
back to
Contents
Page
MOBILE MSISDN PASS-THROUGH

MOBILE MSISDN PASS-THROUGH FLOW DIAGRAM
This Consumer Experience Flow is used when the API has received the MSISDN from the consumers mobile network.

Page 34 of 143
Click to go
back to
Contents
Page
MOBILE MSISDN PASS-THROUGH PAYMENT SCREEN

The Merchant Branded or Unbranded Payment Screens for MSISDN Pass-Through are presented
by the API and are used when the consumer chooses to make a purchase from the Merchant. The
MNO has passed the MSISDN so the consumer does not need to enter it. The API needs to obtain
the Merchant Brand, Merchant Name, Product Name and Price from the Merchant to construct
and display this screen.
Refer to Common Screen items for details of API controlled elements of these screens and
consumer interaction points.
It is the Merchants choice to present the branded or unbranded options. The unbranded option
must contain the name of the Merchant.
Refer to Section C - Transaction Rules for processing detail.
If the API has not received the MSISDN from the mobile network, then other flows should be used.
Optionally, the last four digits of the MSISDN transferred from the mobile network are presented
to the user.
If the consumer clicks the Call to Action button (in this example Buy Now), the API must apply the
charge to the consumers mobile network.
Based on the response from the network, the API must then:
If successful, present the Mobile Payforit Success Screen or return the consumer to the
Merchant for product / service delivery and send a text receipt to the consumer using
appropriate wording and rules from Section E - Text Message Mandated Language.
If unsuccessful, present the Mobile Payforit Failure Screen to the consumer.
Merchant Branded and Unbranded

Payment Screen Samples

Page 35 of 143
Click to go
back to
Contents
Page
MOBILE PAYFORIT SUCCESS SCREEN

With the exception of the Gambling Purchase Flow, the Payforit Success Screen is optional and
should be presented to the consumer by the API once the charge has been successfully applied.
Refer to Common Screen items for details of API controlled elements of these screens and consumer
interaction points.
There are two possible consumer opt-in selections:
Enable Payforit Single Click (Optional for Merchant)
Send offers....(Marketing) (Optional for Merchant)
MNO best practice would be to leave the tick box unchecked so that the consumer actively consents
to Payforit Single Click and future marketing messages.
If the Merchant does not wish to collect marketing opt-in from the consumer or the Merchant does
not require Single Click, then this screen may not be required. In which case the consumer would
need to be directed straight from the relevant Payment Screen to the Merchant site or to the
product or service that they have purchased.
If only the Single Click opt-in is required, the opt-in check box can be presented on the Payforit
Payment Screen.
Once the consumer clicks the Call to Action button, they are directed back to the Merchant for postsale handling. The text receipt (see Section E - Text Message Mandated Language) can also provide a
link back to the Merchant site or to the product or service (see example).
Refer to Section C - Transaction Rules for detailed information on processing of MSISDN, Single Click
permission and marketing permissions.
Payment Success Screen and Receipt

Samples

Page 36 of 143
Click to go
back to
Contents
Page
MOBILE PAYFORIT FAILURE SCREEN

If the charge has not been successfully applied to the consumers mobile network, the API presents
the Payforit Failure Screen.
Payment Failure Screen Sample
See Section C - Transaction Rules for failure reason information to present to the consumer based
on logic supplied by the consumers mobile network or any API logic such as Age Verification.
If the consumer selects the Retry Payment Call to Action, then they must be returned to the
Payment Screen to reconfirm their purchase. The API should not attempt a billing retry on the
network.
If the consumer selects Cancel Purchase, the Merchant should treat this as possible confusion by
the consumer and allow the consumer to retry purchasing of the same or different product.
Failure
reason

Page 37 of 143
Click to go
back to
Contents
Page
MOBILE MSISDN THROUGH MT

MOBILE MSISDN THROUGH MT FLOW
This Consumer Experience Flow is typically used when the consumer is using Wi-Fi and the API needs to obtain the MSISDN from the consumer.

Page 38 of 143
Click to go
back to
Contents
Page
MOBILE MSISDN THROUGH MT SCREEN

The Merchant Branded or Unbranded Payment Screens for Mobile MSISDN through MT are
presented by the API and are used when the consumer chooses to make a purchase from the
Merchant. The API cannot get the MSISDN from the network (i.e. consumer may be in Wi-Fi).
A dropbox for the consumer to select their own network can be provided to avoid failures that
may arise if a number has been ported from one network to another.
The consumer is required to enter their mobile number. If the MSISDN is correctly formatted,
the API sends a text message to the MSISDN containing a unique Payment Code. Refer to
Section E - Text Message Mandated Language for message wording.
If the MSISDN is incorrectly formatted, refer to Mobile MSISDN through MT Payment screen Error Handling. The API then presents the Mobile MSISDN through MT - Code Submit Screen
and follows the processing detailed in Section C - Transaction Rules.
MSISDN through MT Payment Screen

Samples

Page 39 of 143
Click to go
back to
Contents
Page
MOBILE MSISDN THROUGH MT - CODE SUBMIT SCREEN

The Payment Code that is sent to the consumer to validate the MSISDN is required to be entered
by the consumer into the Code Submit Screen (branded version shown, unbranded also
available).
If the consumer enters an invalid code and clicks the Call to Action button, refer to Mobile
MSISDN through MT Payment screen - Error Handling
If the consumer clicks the Resend Code link, the API should send a new unique code to the
MSISDN, but no more than three times in case the MSISDN was incorrect.
If the user clicks the Call to Action button (in this example Buy Now), the API must apply the
Merchant for the product or service delivery and send a text receipt to the consumer using
Code Submit Screen Sample

Page 40 of 143
Click to go
back to
Contents
Page
MOBILE MSISDN THROUGH MT PAYMENT SCREEN - ERROR HANDLING

The error messages are commented out in the HTML file.
If the MSISDN is entered incorrectly and the Call to Action button pressed, the API should
present the red error message Enter valid mobile number in the Payment Screen as detailed
(also in the HTML file).
If the MSISDN is entered incorrectly three times, the API can choose to switch the flow to
Mobile MSISDN through MO Flow or abandon the transaction as it will be clear that the
consumer does not know their mobile number or is trying to falsify the number.
If the Payment Code is entered incorrectly and the Call to Action button pressed, the red error
message Enter valid Code should be presented as detailed.
After three incorrect Payment Code entries, the API should abandon the transaction or switch
to Mobile MSISDN through MO flow if supported.
Payment Screen and Code Submit Screen

(top sections) demonstrating Error Messages

Page 41 of 143
Click to go
back to
Contents
Page
MOBILE MSISDN THROUGH MO

MOBILE MSISDN THROUGH MO FLOW
This Consumer Experience Flow is typically used when the consumer is using Wi-Fi and the API needs to obtain the MSISDN from the consumer though a consumer
initiated text message.

Page 42 of 143
Click to go
back to
Contents
Page
MOBILE MSISDN THROUGH MO SCREEN

The Merchant Branded or Unbranded Payment Screen are presented by the API and are used
when the consumer chooses to make a purchase from the Merchant. The API cannot get the
MSISDN from the network (i.e. consumer may be in Wi-Fi). The consumer must send in by text a
code presented on screen.
Dependant on the unique nature of the Payforit session to the consumer, the keyword (FFFF in
the example) must be unique for a period of time to be able to link the consumers MSISDN
with the relevant Payforit payment session.
The API is able to utilise the Smartphone / feature phone facility to create the message. The
consumer must press send.
Once the text message containing the correct keyword has been received by the API, the API
must apply the charge to the consumers network.
Based on the response from the network the API must;
If successful, present the Mobile Payforit Success Screen or returns the consumer to the
Merchant for product or service delivery and send a text receipt to the consumer using
MSISDN through MO Payment Screen Samples

Page 43 of 143
Click to go
back to
Contents
Page
MOBILE MSISDN THROUGH HYBRID

MOBILE MSISDN THROUGH HYBRID FLOW
This Consumer Experience Flow is typically used when the consumer is using Wi-Fi and the API needs to obtain the MSISDN from the consumer. The API sends a
text message to the MSISDN to which the consumer must reply in order to validate the MSISDN.

Page 44 of 143
Click to go
back to
Contents
Page
MOBILE MSISDN THROUGH HYBRID SCREEN

This Consumer Experience Flow requests the MSISDN from the consumer as in Mobile MSISDN
through MT Flow, but the message sent to the consumer requests a MO text based response
instead. Note the change in information under the Mobile Number entry field.
The consumer is required to enter their mobile number. If the MSISDN is correctly formatted, then
the API sends a text message to the MSISDN containing a keyword response request. Refer to
Section E - Text Message Mandated Language.
If the MSISDN is incorrectly formatted, refer to Mobile MSISDN through MT Payment screen Error Handling.
Once the correct text message containing the keyword has been received by the API, the API must
apply the charge to the consumers mobile network. Based on the response from the network the
API must then:
If the response text message is not received in 5 minutes, present the Mobile Payforit Failure
Screen
MSISDN through Hybrid Payment Screen and

Receipt Message Samples

Page 45 of 143
Click to go
back to
Contents
Page
MOBILE PAYFORIT SINGLE CLICK

The mobile Payforit Single Click Consumer Experience Flow enables consumers to make subsequent purchases from the same Merchant. The consumer must optin to use Payforit Single Click, which expires after the consumer has spent 30 or 90 days have elapsed, whichever is sooner. The consumer can then re-enable
Single Click on the next purchase.

Page 46 of 143
Click to go
back to
Contents
Page
MOBILE SINGLE CLICK BUTTON

On a consumers first purchase from the Merchants service, the consumer will be taken through
one of the Consumer Experience Flows (for mobile) detailed earlier. If the Merchant wishes to offer
Single Click for subsequent purchases by the consumer, the API can present the Single Click opt-in
facility on the Mobile Payforit Success Screen or on one of the Mobile MSISDN Pass-Through
Payment Screens.
The screen examples on this page show a Single Click opt-in on a Payment page and a Single Click
opt-in renewal, which would be presented when the consumer has reached the first of the 30
spend or 90 day limit.
The Single Click opt-in HTML code is embedded in all Success Page HTML files detailed earlier in this
document.
While the consumer remains opted-in, future presentation of
Payforit pricing will be via Single Click buttons served by the API
onto the Merchant screens. See Section C - Transaction Rules for
processing criteria, Section E - Text Message Mandated Language
for Text Message Receipts and Section D - Style Rules for Single
Click button.
An example Single Click button is demonstrated on the left. APIs can
apply to the PFI MG for different button designs to suit their
environment.
Payforit Single Click is NOT available for subscription services.
Single Click opt-in and re-opt in screen samples

(top section shown)

Page 47 of 143
Click to go
back to
Contents
Page
ENHANCED PURCHASE FLOW

Enhanced Purchase Flow is a variation on Payforit Single Click that allows the consumer to make purchases directly from the Merchants service without the need
to move through any of the normal Payforit Consumer Experience Flows and register for Payforit Single Click. To improve security for the consumer, the Merchant
Pages along with Payforit pricing display are served to the consumer by the API.
MOBILE ENHANCED PURCHASE FLOW

Page 48 of 143
Click to go
back to
Contents
Page
ENHANCED PURCHASE FLOW ENTRY

Enhanced Purchase Flow is for services where consumers can access and purchase from a range of
multiple content items offered by the Merchant. All Enhanced Purchase Flow services require the
consumer to proactively accept the Enhanced Purchase Flow terms every 24 hours or calendar day as
per the example shown before they are presented with the content selection options. The pages
allowing selection of the content are controlled entirely by the API (using content supplied by the
Merchant). The content, once purchased is delivered by the Merchant.
Merchants must deliver to a consumer (by MSISDN) a consistent user experience for a single service
across all MNOs. Each service must have the APIs due diligence and risk control process applied
before going live. Content sold via this flow can only ever be purchased once per MSISDN.
The Entry Screen alerts the consumer to the terms of Enhanced Purchase Flow and requires them to
proactively accept these before they can proceed. Once the site has been entered the consumer will
see the header which contains the two consumer pre-ticked selection items, Charge my mobile via
Payforit Single Click and Send offers for similar services to my mobile". If the marketing opt-in is
not required, the option can be removed, but the header box size must remain. See Section D - Style
Rules for details of all Enhanced Purchase Flow elements and the Payforit Assets file for the relevant
HTML files.
If the site is a streaming site this must be explicit. Insert when I select a streamed video into the PFI
header box instead of when I select a video.
Un-ticking Charge my mobile via Payforit Single Click must mean that all purchases from this site
will need to use full screen Payforit Consumer Experience Flows such as Mobile or Embed. See
Consumer Experience Scenarios.
Clicking Exit Website will lead the consumer to a separate instruction page.
All other link and logo interactions are detailed in Common Screen items.
Refer to Section C - Transaction Rules for processing of Enhanced Purchase Flow transactions.
Entry Screen Example

Page 49 of 143
Click to go
back to
Contents
Page
ENHANCED PURCHASE FLOW SELECTION SCREEN
Grid Style
Header box rules apply

Thumbnail rules apply
Pricing rules apply
Space between first and second rows
should be a minimum of 3%
Image maximum height 500px,
centred
Clickable area maximum width 80%,
10% from each edge.
Only the image is clickable to charge
Call to action should not overshadow
pricing
Carousel Style
Content Selection Screen Sample

Pricing rules apply
centred
10% from each edge.
Images are not clickable to charge
There must be scroll buttons
(next/previous)
pricing
List Style
Hero Style (Shown in Example)

Pricing rules apply
Space between first and second rows
should be a minimum of 3%
centred
10% from each edge.
pricing

Pricing rules apply
Space between rows should be a
minimum of 3%
centred
10% from each edge.
pricing
Pricing can be to the side

Page 50 of 143
Click
Click to
to go
go
back
back to
to
Contents
Contents
Page
Page
ENHANCED PURCHASE FLOW CONTENT DELIVERY SCREEN
Content Delivery Screen, Exit & Receipt Samples
This screen is also controlled by the API (using content supplied by the Merchant) and enables
the consumer to receive (delivery or stream) the purchased content.
The consumer may make subsequent content purchases at the same or lower price using a link on
the delivery page with the appropriate price warning as seen in this example.
The API must offer a 10 minute trial period for each content item, by suspending billing for that
content item until expiry of 10 minutes (advised to consumer through the [time] parameter in this
example) and must display the text: This mobile will be charged (price) because a selection was
made on the previous screen. If you are not satisfied, you may cancel this charge by clicking here
before [time] The cancellation rule only applies to experience goods. An experience good is a
product or service where product characteristics, such as quality or price, are difficult to observe in
advance, but these characteristics can be ascertained upon consumption.
If the consumer elects to cancel the purchase and thus the charge, then the API can (optionally)
prevent the consumer from making subsequent purchases. The API must route the consumer from
the service as in the example. All pending charges and receipts for this content (ie those that have
not yet passed the 10 minute suspension period) are cancelled but those that have been consumed
(ie passed the 10 minute expiry point) can be charged and a receipt should be sent detailing this,
aggregated if more than one charge is relevant.
Time
Cancelled
Not cancelled
receipt text
Transaction A
10:00
10:16
10:30
Transaction B
10:05
10:16
10:30
Transaction C
10:10
10:16
10:30
Transaction D
10:15
10:16
10:30
Transaction E
11:30
Site Exited
11:45
A&B billed
All billed
If the consumer does not cancel the purchase, the API can charge to the mobile network as normal
and must send receipts for all purchases using the text messages detailed in Section E - Text
Message Mandated Language.
Please refer to Section C - Transaction Rules for processing of 10 minute trial for Enhanced
Purchase Flow transactions.

Page 51 of 143
Click to go
back to
Contents
Page
EMBED METHOD FOR HTML5 DEVICES

Embed Method for devices that support HTML5 (mobile or tablet) provides an improved Consumer Experience Flow as the Payforit payment panel is served by
the API into an iFrame within the Merchant service, giving a richer experience and improved brand continuity for the Merchant.
A mock-up (non-gambling) App is demonstrated here to show the use of Embed method. This game allows the consumer to purchase credits to play.
Top up
Credits
Clicked
Payment
iFrame
Credit
Added

Page 52 of 143
Embed method gives Merchants who run web apps the ability to target services at smartphones and tablets and be able to monetise the app usage through
mobile billing payment methods, thereby increasing the potential reach of the service. The Embed method is designed to provide a mobile billing option within an
existing web accessed service. The Merchant for the existing service should already provide a full set of consumer terms and conditions and contact numbers for
help out side of the Payforit screens.
Embed Method requires the MSISDN of the consumer (in order to effect billing) either transferred by the mobile network to the API (MSISDN Pass Through),
acquired directly from the consumer and then verified by the API (MT flow), acquired via an inbound text message to the API shortcode (MO Flow) or a
combination of the MT and MO methods (Hybrid Flow).
Each of the Embed Method options is detailed below with their own flowchart and screen samples.
The iFrame is designed to be presented by the API inside the Merchant page and to be able to adopt the brand style of the Merchant. This means that the
consumer will not leave the Merchant environment to complete the purchase. Presentation inside the Merchant environment, inside an iFrame, will naturally
constrain the comprehensive display of essential information that is available from other Payforit payment methods.
APIs will need to enhance ongoing risk assessment of the Merchants who are deploying this facility.
It is the APIs responsibility to ensure contact details are clearly visible to the consumer on the existing site. If the API wishes to add contact details to the iFrame,
then the frame height should be increased by 20 pixels and the following recommended text added to the lower part of the iFrame: "Help? [non premium rate
phone number] or [email address]". (Note: email address is additional to phone number, not a substitution).
The iFrame size is recommended to be 200 pixels (width) by 120 pixels (height)
for mobile devices (handset style) and 300 pixels (width) by 200 pixels (height)
for tablets. These sizes can be increased proportionally but the iFrame must not
occupy more than 80% of the available screen display.
The example on the previous page shows handset style suggested presentation,
the example on this page shows tablet style suggested presentation.
The Merchant decides where the iFrame is positioned on their page and what
colours to use for background, frame border, colour and font if required.
See Section D - Style Rules for iFrame presentation.

Page 53 of 143
Click to go
back to
Contents
Page
EMBED MSISDN PASS-THROUGH FLOW DIAGRAM

This Consumer Experience Flow assumes that the API has received the MSISDN from the consumers mobile network.

Page 54 of 143
Click to go
back to
Contents
Page
EMBED MSISDN PASS-THROUGH PAYMENT IFRAME

The Payment iFrame for MSISDN Pass-Through is presented by the API into the Merchant HTML5
compatible service presented in either handset format or tablet format and would be as a result of the
consumer committing to make a purchase from the Merchant. The consumers MNO has passed the
MSISDN so the consumer doesnt need to enter it. Where the API has detected the customer is using a
device that cannot receive SMS the Receipt Via Email screen is presented by the API as an alternative.
The email address should be validated on the customer side to prevent typos. The email address can be
stored by the API so that the user doesnt need to re-enter on each purchase. The user should be able to
switch to use an alternative mobile number.
The API needs to obtain the Merchant product name and price from the Merchant to construct this
iFrame.
Embed iFrame Samples

Without contact details
With contact details (recommended)
interaction points. Refer to Section C - Transaction Rules for processing detail.
If the API has not received the MSISDN from the mobile network, then other flows should be used.The
last four digits of the MSISDN served from the mobile network are presented to the user. If the consumer
clicks the Call to Action button (in this example Buy Now), the API must apply the charge to the
consumers mobile network.If the API has presented the consumer support contact details as
demonstrated in the second sample on this page, then the next iFrame (Success iFrame) is optional.
Based on the response from the network, the API must then;
If successful, present the optional Embed Payforit Success iFrame or close the iFrame and instruct an
update to the Merchant page relevant to the purchase that has been made. The API sends a text
receipt to the consumer using appropriate wording and rules from Section E - Text Message
Mandated Language.
If unsuccessful, presents the Embed Payforit Failure iFrame to the consumer.
Receipt Via Email Screen

Page 55 of 143
Click to go
back to
Contents
Page
EMBED PAYFORIT SUCCESS IFRAME

The Payforit Success Screen should be presented to the consumer by the API once the charge has
been successfully applied.
There are two possible consumer opt-in selections:
Enable Payforit Single Click (Optional for Merchant and for web services is only usable on
services with a username and password control function)
MNO best practice would be to leave the tick boxes unchecked so that the consumer actively
consents to Payforit Single Click and future marketing messages.
If the Merchant does not wish to collect marketing opt-in from the consumer or the Merchant does
not require Single Click, then this iFrame may not need to be presented if the consumer contact
details have been presented in the previous iFrame. In which case, the Merchant will need to close
the iFrame and provide the product / service that the consumer purchased.
The API must send a text receipt (see Section E - Text Message Mandated Language). This can also
provide a link back to the Merchant for correct handling from this point.
Once the consumer clicks the Call to Action button, the Merchant closes the iFrame and provides
the product or service that the consumer purchased.
Refer to Section C - Transaction Rules for detailed information on processing of MSISDN, Single Click
permission and marketing permissions.
Payment Success iFrame and Receipt

Message Samples

Page 56 of 143
Click to go
back to
Contents
Page
EMBED PAYFORIT FAILURE IFRAME

If the charge has not been successfully applied to the consumers mobile network, the API
presents the Payforit Failure iFrame.
See Section C - Transaction Rules for failure reason information to present to the consumer
based on logic supplied by the consumers mobile network or any API logic such as Age
Verification.
network.
If the consumer selects Cancel Purchase, the Merchant should return the consumer to the
point before the purchase commenced.
Payment Failure iFrame Sample

Page 57 of 143
Click to go
back to
Contents
Page
EMBED MSISDN THROUGH MT

EMBED MSISDN THROUGH MT FLOW
This Consumer Experience Flow is typically used when the consumer is using Wi-Fi and the API needs to obtain the MSISDN from the consumer.

Page 58 of 143
Click to go
back to
Contents
Page
EMBED MSISDN THROUGH MT IFRAME

The Embed MSISDN through MT iFrame is presented by the API and is used when the consumer
chooses to make a purchase from the Merchant. The API cannot get the MSISDN from the
mobile network (i.e. consumer may be in Wi-Fi).
consumer interaction points. Refer to Section C - Transaction Rules for detailed processing
rules.
The consumer is required to enter their mobile number. If the number is incorrectly formatted,
the API serves the error text as shown. If the MSISDN is invalid three times, then the API should
consider moving to the Embed MSISDN through MO flow if supported or cancel the purchase.
If the MSISDN is correctly formatted, then the API sends a text message to the MSISDN
containing a unique Payment Code. Refer to Section E - Text Message Mandated Language for
message wording.
The API then presents the next iFrame in this sequence, the Code entry iFrame as shown with
the Call to Action button correctly worded for the transaction. The Payment Code that is sent to
the consumer to validate the MSISDN is required to be entered by the consumer. If the incorrect
code is entered, the API presents the error text as shown. After three attempts, the API should
abandon the transaction or switch to Embed MSISDN through MO flow if supported.
If the correct code is entered and the user clicks the Call to Action button (in this example Buy
Now), the API must apply the charge to the consumers mobile network.
If successful, present the Embed Payforit Success iFrame and send a text receipt to the
consumer using appropriate wording and rules from Section E - Text Message Mandated
Language.
If unsuccessful, present the Embed Payforit Failure iFrame to the consumer.
Embed MSISDN through MT iFrame Samples

Page 59 of 143
Click to go
back to
Contents
Page
EMBED MSISDN THROUGH MO

EMBED MSISDN THROUGH MO IFRAME

Page 60 of 143
Click to go
back to
Contents
Page
EMBED MSISDN THROUGH MO IFRAME

The Payment iFrame is presented by the API and is used when the consumer chooses to make a
purchase from the Merchant. The API cannot get the MSISDN from the network (i.e. consumer may
be in Wi-Fi). The consumer must send in by text, the code presented on screen.
Embed MSISDN through MO iFrame

Samples

If the product being purchased is unique to the consumer, the keyword (FFFF in this example) must
be unique for a period of time to be able to associate the consumers MSISDN with the relevant
Payforit payment session.
The API is able to utilise the Smartphone/feature phone facility to create the message. The
consumer must press send. The Call to Action button can say Click to Send Text in this instance;
otherwise, it should say Continue.
Once the text message containing the correct unique keyword has been received by the API, the
API must apply the charge to the consumers network.
Language
If unsuccessful, present the Embed Payforit Failure iFrame to the consumer
Use when text message is to be created

automatically

Page 61 of 143
Click to go
back to
Contents
Page
EMBED MSISDN THROUGH HYBRID

EMBED MSISDN THROUGH HYBRID FLOW
text message to the MSISDN to which the consumer must reply to validate the MSISDN.

Page 62 of 143
Click to go
back to
Contents
Page
EMBED MSISDN THROUGH HYBRID SCREEN

This Consumer Experience Flow requests the MSISDN from the consumer as in Embed MSISDN
through MT flow but the message sent to the consumer requests a MO text based response
The consumer is required to enter their mobile number. If the number is incorrectly formatted, the
API serves the error text as shown. If the MSISDN is invalid three times, then the API should
consider moving to the Embed MSISDN through MO flow if supported or cancel the purchase. If
the MSISDN is correctly formatted, then the API sends a text message to the MSISDN containing a
keyword response request. Refer to Section E - Text Message Mandated Language for message
wording.
Once the text message containing the keyword has been received by the API, the API must apply
the charge to the consumers mobile network.
Language
If unsuccessful, present the Embed Payforit Failure iFrame to the consumer
If the response text message is not received in 5 minutes, present the Embed Payforit Failure
iFrame.
Embed MSISDN through Hybrid iFrame

Samples

Page 63 of 143
Click to go
back to
Contents
Page
EMBED SINGLE CLICK

EMBED SINGLE CLICK FLOW
The Embed Payforit Single Click Consumer Experience Flow enables consumers to make subsequent purchases from the same Merchant. The consumer must optin to use Payforit Single Click which expires after the consumer has spent 30 or 90 days have elapsed, whichever is sooner. The consumer can then re-enable
Single Click on the next purchase.

Page 64 of 143
Click to go
back to
Contents
Page
EMBED SINGLE CLICK BUTTON

one of the Consumer Experience Flows (Embed) detailed earlier. If the Merchant wishes to offer
facility on the Embed Payforit Success iFrame.
The screen examples on this page show a Single Click opt-in on a Payment Success page and a Single
Click opt-in re-enable which would be presented when the consumer has reached the first of the
30 spend or 90 day limits.
While the consumer remains opted-in, future presentation of Payforit pricing will be via Single Click
buttons served by the API onto the Merchant screens. See Section C - Transaction Rules for
processing criteria Section E - Text Message Mandated Language for Text Message Receipts and
Section D - Style Rules for Single Click button.
Credits: 15
Buy 10 Credits 1
An example Single Click button is

demonstrated on the left.
APIs can apply to the PFI MG for
different button designs to suit their
environment.
Change Stake
Spin the Wheel
Payforit Single Click is NOT available

for subscription services.
Single Click Opt-in and Re-enable Samples

Page 65 of 143
Click to go
back to
Contents
Page
WEB PAYFORIT CONSUMER EXPERIENCE

Web Payforit Consumer Experience Flow is designed primarily for consumers that wish to buy digital products and services discovered while browsing the internet
on their PC, Mac or other device and charge the purchase to their mobile account. The assumption therefore is that the consumer will have to submit the MSISDN
of the account to be charged either through manual entry (MT Flow) or by sending a unique keyword to a shortcode (MO Flow) or a combination of these two
(Hybrid Flow). Once the MSISDN has been verified, and the consumer authorises the charge, it can be applied to the consumers mobile network.
However, an increasing amount of PCs, Macs and other devices are accessing the internet using embedded 3/4G SIM cards, dongles, tethering or 3G/4G Wi-Fi
devices and the MSISDN of the access facility may be transferred to the API via the mobile network (dependant on individual network logic and policies). Some
consumers are unaware that their dongle or Wi-Fi device can be charged, so all the Payforit Consumer Experience Flows include a declaration of the last four digits
of the MSISDN that will be charged to improve this awareness.
Web Payforit screens are to be presented by the API either inside the Merchant page as an iFrame to be called when the consumer makes a commitment to
purchase or as a pop-up (understanding the limitations of pop-ups when blockers are enabled) or as a separate web page that the consumer is redirected to for
the purchase. An example is shown below of a consumers experience playing a web game and purchasing credits for the game (MT Flow).
Top up Credits
Clicked
Each of the Web Payforit options is detailed below with their own flowchart and screen samples.

Page 66 of 143
Click to go
back to
Contents
Page
WEB MSISDN PASS-THROUGH

WEB MSISDN PASS-THROUGH FLOW DIAGRAM

Page 67 of 143
Click to go
back to
Contents
Page
WEB MSISDN PASS-THROUGH PAYMENT SCREEN

The Merchant Branded or Unbranded Payment Screens for MSISDN Pass through is presented by
the API and is used when the consumer chooses to make a purchase from the Merchant. The
consumers MNO has passed the MSISDN so the consumer doesnt need to enter it. The API needs
to obtain the Merchant Brand, Merchant Name, Product Name and Price from the Merchant to
construct and display this screen. Where the API has detected the customer is using a device that
cannot receive SMS Receipt Via Email screen is presented by the API as an alternative. The email
address should be validated on the customer side to prevent typos. The email address can be stored
by the API so that the user doesnt need to re-enter on each purchase. The user should be able to
switch to use an alternative mobile number.
Web MSISDN pass through Payment Screen
consumer interaction points. Refer to Section C - Transaction Rules for processing detail.
If the API has not received the MSISDN from the mobile network, then other flows should be used.
The last four digits of the MSISDN served from the mobile network are presented to the user.
If the consumer clicks the Call to Action button (in this example Buy Now), the API must apply the
If successful, present the Web Payforit success Screen or returns the consumer to the Merchant
for product or service delivery and send a text receipt to the consumer using appropriate
wording and rules from Section E - Text Message Mandated Language.
If unsuccessful, presents the Web Payforit failure Screen to the consumer
Receipt Via Email

Screen

Page 68 of 143
Click to go
back to
Contents
Page
WEB PAYFORIT SUCCESS SCREEN

The Payforit Success Screen is optional and should be presented to the consumer by the API
once the charge has been successfully applied.
There are two possible consumer opt-in selections;
Enable Payforit Single Click (Optional for Merchant)
MNO best practice would be to leave the tick box unchecked so that the consumer actively
consents to Payforit Single Click and further marketing messages.
If the Merchant does not wish to collect marketing opt-in from the consumer or the Merchant
does not require Single Click, then this screen may not be required. In which case, the
consumer would need to be directed straight from the relevant Payment Screen to the
Merchant or directly to the product or service that the consumer purchased.
If only the Single Click opt-in is required, the opt-in check box can be presented on the Payforit
Payment Screen.
Once the consumer clicks the Call to Action button, they are directed back to the Merchant for
post-sale handling. The text receipt (see Section E - Text Message Mandated Language) also
provides a link back to the Merchant.
Refer to Section C - Transaction Rules for detailed information on processing of MSISDN, Single
Click permission and marketing permissions.
Payment Success Screen Sample

Page 69 of 143
Click to go
back to
Contents
Page
WEB PAYFORIT FAILURE SCREEN

If the charge has not been successfully applied to the consumers mobile network, the API
presents the Payforit Failure Screen.
Payment Failure Screen Sample
See Section C - Transaction Rules for failure reason information to present to the consumer
based on logic supplied by the consumers mobile network or any API logic such as Age
Verification.
Payment Screen to reconfirm their purchase or to utilise the optional Use alternate mobile
number option.
The API should not attempt a billing retry on the network.
Failure
reason

Page 70 of 143
Click to go
back to
Contents
Page
WEB MSISDN THROUGH MT

WEB MSISDN THROUGH MT FLOW
This Consumer Experience Flow is used when the consumer is using Wi-Fi and the API needs to obtain the MSISDN from the consumer.

Page 71 of 143
Click to go
back to
Contents
Page
WEB MSISDN THROUGH MT SCREEN

The Merchant Branded or Unbranded Payment Screens for Mobile MSISDN through MT is
presented by the API and is used when the consumer chooses to make a purchase from the
Merchant. The API cannot get the MSISDN from the network (i.e. consumer may be in Wi-Fi
or using a separate computer).It is the Merchants choice to present the branded or
unbranded options. The unbranded option must contain the name of the Merchant.
Please note the 1, 2, 3 Step indicators on the screen that will show the consumer where they
are in the process.
then the API sends a text message to the MSISDN containing a unique Payment Code. Refer to
Section E - Text Message Mandated Language for message wording.
If the MSISDN is incorrectly formatted, refer to Web MSISDN through MT Payment screen Error Handling
The API then presents the Web MSISDN through MT - Code Submit Screen and follows the
processing detailed in Section C - Transaction Rules.
Web MSISDN through MT Payment Screen

Samples

Page 72 of 143
Click to go
back to
Contents
Page
WEB MSISDN THROUGH MT - CODE SUBMIT SCREEN

The Payment Code that is sent to the consumer to validate the MSISDN is required to be
entered by the consumer into the Code Submit Screen (branded version shown, unbranded
also available)
If the consumer enters an invalid code and clicks the Call to Action button, refer to Web
MSISDN through MT Payment screen - Error Handling
If the consumer clicks the Resend Code link, the API should send a new unique code to the
MSISDN, but no more than three times in case the MSISDN was incorrect.
If the user clicks the Call to Action button (in this example Buy Now), the API must apply the
If successful, present the Web Payforit success Screen or return the consumer to the
Merchant for product /service delivery and send a text receipt to the consumer using
If unsuccessful, present the Web Payforit failure Screen to the consumer
Code Submit Screen Samples

Page 73 of 143
Click to go
back to
Contents
Page
WEB MSISDN THROUGH MT PAYMENT SCREEN - ERROR HANDLING

If the MSISDN is entered incorrectly and the Call to Action button pressed, the API should present
the red error message Enter valid mobile number into the Payment Screen as detailed (also in the
HTML file).
If the MSISDN is entered incorrectly three times, the API can choose to switch the flow to Web
MSISDN through MO Flow or abandon the transaction as it will be clear that the consumer does
not know their mobile number or is trying to falsify the number.
If the Payment Code is entered incorrectly and the Call to Action button pressed, the red error
message Enter valid Code should be presented as detailed.
After three incorrect Payment Code entries, the API should abandon the transaction or switch to
Web MSISDN through MO Flow if supported.
Sample MT entry Screen and code entry

Screen Samples with Error Messages

Page 74 of 143
Click to go
back to
Contents
Page
WEB MSISDN THROUGH MO

WEB MSISDN THROUGH MO FLOW

Page 75 of 143
WEB MSISDN THROUGH MO SCREEN

The Merchant Branded or Unbranded Payment Screen is presented by the API and is used when
the consumer chooses to make a purchase from the Merchant. The API cannot get the MSISDN
from the network (i.e. consumer may be in Wi-Fi). The consumer must send in by text a code
presented on screen.
Dependant on the unique nature of the Payforit session to the consumer, the keyword (FFFF in this
example) must be unique for a period of time to be able to link the consumers MSISDN with the
relevant Payforit payment session.
Once the text message containing the correct keyword has been received by the API, the API must
apply the charge to the consumers mobile network.
If successful, present the Web Payforit success Screen or return the consumer to the Merchant
for product or service delivery and send a text receipt to the consumer using appropriate
wording and rules from Section E - Text Message Mandated Language.
Web MSISDN through MO Screen

Samples

Page 76 of 143
Click to go
back to
Contents
Page
WEB MSISDN THROUGH HYBRID

WEB MSISDN THROUGH HYBRID FLOW
text message to the MSISDN to which the consumer must reply in order to validate the MSISDN.

Page 77 of 143
Click to go
back to
Contents
Page
WEB MSISDN THROUGH HYBRID SCREEN

This Consumer Experience Flow requests the MSISDN from the consumer as in Web MSISDN
through MT Flow, but the message sent to the consumer requests a MO text based response
then the API sends a text message to the MSISDN containing a keyword response request.
Refer to Section E - Text Message Mandated Language for message wording.
If the MSISDN is incorrectly formatted, refer to Web MSISDN through MT Payment screen Error Handling.
Once the correct text message containing the keyword has been received by the API, the API
must apply the charge to the consumers mobile network. Based on the response from the
network, the API must then:
If successful, present the Web Payforit success Screen or return the consumer to the
If the response text message is not received in 5 minutes, present the Web Payforit failure
Screen
Web MSISDN through Hybrid Payment

Screen and Receipt Samples

Page 78 of 143
Click to go
back to
Contents
Page
WEB PAYFORIT SINGLE CLICK

The Web Payforit Single Click Consumer Experience Flow enables consumers to make subsequent purchases from the same Merchant. The consumer must opt-in
to use Payforit Single Click, which expires after the consumer has spent 30 or 90 days have elapsed whichever is sooner. The consumer can then re-enable Single
Click on the next purchase.
Web Single Click is only available where the MSISDN of the consumer is transferred by the mobile network or that the consumer has an account relationship with
the Merchant through a Username/Password login facility.

Page 79 of 143
Click to go
back to
Contents
Page
WEB SINGLE CLICK BUTTON

one of the Consumer Experience Flows (for Web) detailed earlier. If the Merchant wishes to offer
facility on the Web Payforit success Screen or on one of the Web Payment pages.
The screen examples on this page show a Single Click opt-in on a Payment page and a Single Click
opt-in renewal, which would be presented when the consumer has reached the first of the 30
spend or 90 day limits. The HTML code for this option is embedded in the relevant HTML files and
commented out.
While the consumer remains opted-in, future presentation of Payforit pricing will be via Single Click
buttons served by the API onto the Merchant Screens.
See Section C - Transaction Rules for processing criteria, Section E - Text Message Mandated
Language for Text Message Receipts and Section D - Style Rules for the Single Click button.
Payforit Single Click is NOT available for subscription services.
An example Single Click button is

demonstrated on the left. APIs and
Merchants can apply to the PFI MG for
different button designs to suit their
environment.
Single Click Opt-in and Re-enable Screen

Samples

Page 80 of 143
Click to go
back to
Contents
Page
GAMBLING PURCHASE FLOW

GAMBLING PURCHASE FLOW DIAGRAM
GAMBLING PURCHASE FLOW

Page 81 of 143
Click to go
back to
Contents
Page
GAMBLING PURCHASE FLOW PAYMENT SCREEN

The Payforit Gambling Purchase Flow resembles the Mobile MSISDN Pass-Through flow with only
some slight changes to suit gambling operators.
The merchant logo can be included and the wording Deposit Now andDeposit xx.xx are
allowed.
The pricing box can be made to be a drop down box allowing multiple deposit options
up to a maximum of 30.00.
If the consumer clicks the Call to Action button (in this example Deposit Now), the API must apply
the charge to the consumers mobile network.
Merchant for product / service delivery and send a text receipt to the consumer using
Gambling Purchase Flow Sample

Page 82 of 143
Click to go
back to
Contents
Page
GAMBLING PURCHASE SUCCESS SCREEN

The Payforit Success Screen is not optional and should be presented to the consumer by the API once
the charge has been successfully applied. It can include space for marketing rather than the
marketing and single click tick boxes.
interaction points.
FreeMsg: Thank you for your deposit of xx for Service name from Merchant name. Your
gambling account has been credited. Help? (Telephone) or visit (URL)
Once the consumer clicks the Call to Action button, they are directed back to the Merchant for postsale handling. The text receipt (see Section E - Text Message Mandated Language) can also provide a
link back to the Merchant site or to the product or service (see example).
Deposit Success Screen

Page 83 of 143
Click to go
back to
Contents
Page
GAMBLING PURCHASE FAILURE SCREEN

If the charge has not been successfully applied to the consumers mobile network, the API presents
the Payforit Failure Screen. The Payment Failure Screen states Deposit Failed with the following
information:
Top up your mobile phone account by accessing (MNO contact number) now.
See Section C - Transaction Rules for failure reason information to present to the consumer based
on logic supplied by the consumers mobile network or any API logic such as Age Verification.
network.
If the consumer selects Cancel Purchase, the Merchant should treat this as possible confusion by
the consumer and allow the consumer to retry purchasing of the same or different product.
Deposit Failure Screen Sample

Page 84 of 143
Click to go
back to
Contents
Page
DOUBLE OPT-IN FLOW

Double Opt-In Flow allows the user to purchase time-based access to services or promotions, or purchase virtual goods or service credits which can be offered by
the merchant using a one time or recurring payment mechanic.
DOUBLE OPT-IN FLOW

Page 85 of 143
Click to go
back to
Contents
Page
DOUBLE OPT-IN FLOW CONSUMER EXPERIENCE

Content Selection Screen Sample
Double Opt-In Flow allows the user to purchase time-based access to services or promotions, or
purchase virtual goods or service credits which can be offered by the merchant using a one time or
recurring payment mechanic. Merchants must deliver to a consumer (by MSISDN) a consistent user
experience for a single service or promotion across all APIs. Each service or promotion must have the
APIs due diligence and risk control process applied before going live. The following screens are
hosted by the API.
In the example shown, the content is accessible through purchasing time-based access. The content
is delivered by the merchant once the time-based access is purchased and is available to the
consumer up until the access period has elapsed.
The API must offer a 10 minute trial period for any service containing sexual adult visual content by
suspending billing for that item until the expiry of 10 minutes and must also display the text: This
mobile will be charged (price) because a selection was made on the previous screen. If you are not
satisfied, you may cancel this charge by clicking here before [time]. This must be placed on a page
hosted by the API and shown to the consumer immediately after the purchase has taken place.
If the consumer elects to cancel the charge, the current and all prior suspended billing transactions
within the last 10 minutes are cancelled. The receipt for any purchases successfully charged is
aggregated and sent immediately.
When accessing the page, the consumer will see the header which floats at the top of the screen if
the user scrolls the page and which contains a pre-ticked select box of Send offers for similar
services to my mobile. See Section D Style Rules for details of header layout. If the marketing opt-in
is not required, the option can be removed, but the header box size must remain.
All other link and logo interactions are detailed in Common Screen Items
Refer to Section C Transaction Rules for processing of Double Opt-In Flow transactions.

Page 86 of 143
Click to go
back to
Contents
Page
DOUBLE OPT-IN FLOW SELECTION SCREEN & RECEIPT
In the example shown, there are options for purchasing time-based access. These must be listed
in ascending order. The content is delivered by the merchant once the required time-based access
is purchased and is available to the consumer up until the access period has elapsed.

Page 87 of 143
Click
Click to
to go
go
back
back to
to
Contents
Contents
Page
Page
DOUBLE OPT-IN FLOW PURCHASE SCREEN

This screen is hosted by the API and allows the consumer to purchase time-based access to services
or promotions (minimum 24 hours access), or purchase virtual goods or service credits.
The consumer can purchase access by pressing the first opt-in purchase button which also contains
the appropriate pricing information. The first opt-in purchase button should be displayed as in the
example images starting with Get or other permitted word.
Clicking the Exit website button will lead the consumer to a separate instruction page. This button
can be used at anytime even if the first opt-in button has been clicked.
Once clicked the wording on the first opt-in button changes without affecting any other elements
on the page. The button becomes the second opt-in and prompts the consumer that a charge will
be made to their mobile bill and confirms they wish to continue. The button and its text should be
presented in a different colour on the second opt-in to make the change more visually apparent.
Once the second opt-in button has been clicked the consumer will be billed and directed to the
content hosted by the merchant. The content is accessible until the time window has closed when
they will then be served again with the double opt-in payment screens to enable them to purchase
further access.
Recurring Payments
Recurring payment options of weekly or monthly frequency may have an initial free period and the
welcome message should be sent immediately instead of the receipt message. Thereafter
reminder messages must be sent for every 20 billed or one month, whichever is soonest. The call
to action text must start with Join instead of Get or other permitted words.
The API must host the shortcode used for the STOP command and the STOP requests must be
processed immediately. If the API has not detected evidence of service usage in a 90 day period
then the API must terminate that consumers recurring payment immediately. Refer to Section C Transaction Rules for processing detail.
Purchase Screen, Exit, STOP & Receipt Samples

Page 88 of 143
Click to go
back to
Contents
Page
PAYFORIT INFORMATION PAGES

Payforit Information pages comprise of the following mandatory sets of information that is
available to consumers when they click the relevant link on any Payforit page. See Common Screen
items for details of links. The pages are;
About Payforit: Is an Information page which summarises what Payforit is and is linked to the
Payforit Logo, the hyperlinked words Payforit and Payforit terms in all Consumer
Experience Flows.
Merchant Terms: This page details the relevant terms of the Merchants service, must be clear
to the consumer and must provide all information that would affect a consumers decision to
purchase. It is best practice for complex terms for services such as competitions, that key facts
are extracted from the terms and presented to the consumer first. In Gambling Purchase Flows
the consumer must be informed that they cannot re-credit any winnings from their gambling
account to their mobile account.
Single Click Information: This page details how the Single Click functionality works.
Need Help? This section is detailed on the payment page of all Consumer Experience Flows
except Embed and In-App, where it will need to be included in the About Payforit page.
The HTML files to produce the screens are detailed with each flow.
Payforit Information Screen Samples

Page 89 of 143
Click to go
back to
Contents
Page
ABOUT PAYFORIT
Embed_Payforit_Info.html
Mobile_Payforit_Info.html
Web_Payforit_Info.html
Mandatory Text: (New Text)

Payforit is a payment flow developed by the UK mobile networks operators (MNO), in consultation with the industry and
PhonepayPlus, to make buying products and services via a mobile phone or other device simple and clear for you.
When you buy a product or service using Payforit your contract is with the party selling the product or service (the seller) not with
your MNO. Your MNO has agreed with the seller simply to charge the amount directly to your bill or prepay account.
When choosing to pay by mobile, you are either entering your mobile number or agreeing for your MNO to pass your number onto the
seller in order to complete the transaction. The vendor may use your mobile number in accordance with its privacy policy and applicable
terms and conditions.
Payforit is not a legal entity and is not a party to that transaction for the product or service. You are therefore wholly responsible for
checking youre happy with the price, product or service and the seller. Any rights you may have (Statutory or otherwise) for things like
refunds, replacements or returns are between you and the seller, but your MNO will help if you are having difficulty.
This payment flow is operated under contract by [API NAME] and our contact details are [API NUMBER]

Page 90 of 143
Click to go
back to
Contents
Page
SINGLE CLICK INFORMATION

Mobile and Web Mandatory Text:
Mobile_Single_Click_Information.html
Web_Single_Click_Information.html
About Payforit Single Click
Ticking the "Enable Payforit Single Click Payment" box allows you to buy from this Merchant again with a single click.
You can use Payforit Single Click for 90 days or until you've spent 30, easily extended by ticking the "Re-enable Payforit Single Click"
box when prompted.
Make multiple purchases more quickly and easily than ever.
Embed Mandatory Text:
Embed_Single_Click_Information.html
About Payforit Single Click

Ticking the "Enable single click payments" box allows you to buy from this merchant again, for 90 days or until you've spent 30, with
effectively one click.
NEED HELP?
The Need Help? section is on the footer of all Payforit Consumer Experience Flows except Embed.
Mandatory Text:
Need Help?
You can contact us by calling [non-premium rate phone number] or emailing [email address]. Your purchase is subject to Merchant and
Payforit terms and the cost will appear on your next mobile bill or will be deducted from your prepay balance. The UK mobile network
operators created and support Payforit to enable secure payments.

Page 91 of 143
Click to go
back to
Contents
Page
PAYFORIT IN-APP CHARGING

INTRODUCTION
Consumers running applications on their smartphones, tablets and other devices that are capable of accessing and running applications are able (subject to
consumers limitations on their mobile account) to pay for purchases of products and services WITHIN the application and charge the amount to their mobile
account or prepay balance. This is known as In-App charging.
When a consumer is using an App it is not possible to pay for features or services using the standard Payforit methodologies. A dedicated secure Payment Library
that is capable of replicating the Payforit Scheme Rules needs to reside within the App.
The environment for In-App charging does not provide the capability for the presentation layer of the payment part of the consumers experience with the App to
be presented by the API as with all other Payforit experiences, so the PFI MG have determined that Payforit In-App charging will be provided via reviewed and
accepted Payment Library Companies that will manage the consumer experience to the requirements of the Payforit Scheme and perform the consumer
protection role alongside the API.
The API and the Payment Library Company will collectively seek acceptance from the PFI MG to proceed with In-App charging. The criteria for acceptance is
detailed in Section I - Payment Libraries Review and Acceptance Criteria.

Page 92 of 143
Click to go
back to
Contents
Page
IN-APP CONSUMER EXPERIENCE FLOW

Consumer Experience Flows are designed by the Payment Library Company alongside the API
and presented to the PFI MG for review and acceptance. All Payment Flows must meet the
following requirements, which are consistent with other Payforit Consumer Experience Flows:
A Payment Frame replicating as a minimum, the Embedded Purchase iFrame and

Embedded Success iFrame (see Embed Method for HTML5 Devices) must be presented
Wording presented to the consumer must replicate the Payforit principles of pricing
transparency and clarity and use where possible the wording in Section D - Style Rules
Pricing must include Merchant details, product description and the price in the format
detailed in Section D - Style Rules
Call-to-action must be presented as a button using Buy Now, Donate Now or
Subscribe and be consistent with any expectation set previously
There must be a clear mechanism for the consumer to cancel the proposed purchase and
return to the App
Payforit trust mark must be included within the payment frame for UK consumers.
Merchant, Payment Library or API Customer care details must be readily available. Calls
must be routed through API for volume analysis
Merchant terms and conditions must be easily accessible, meaningful and be consistent
with the service
All purchases will result in a text receipt using wording defined in Section E - Text
Message Mandated Language
Customer care procedures must comply with Payforit Scheme Rules Section G Customer
Service Requirements
Sample In-App Payment Flow

Page 93 of 143
Click to go
back to
Contents
Page
IN-APP USER VERIFICATION

In order to gain the MSISDN of the consumer, a range of verification methods should be used inside the App Payment Library;
MSISDN Pass through: The App performs a background HTTP request to the API. The API receives the MSISDN from the consumers MNO, aliases the
MSISDN and shares the alias with the Payment Library Company for subsequent billing
MO Method: The App, with permission from the consumer, sends a coded text message to a shortcode managed by the API. If there are any chargeable
messages then the consumer must consent to the charge. If the shortcode is zero rated, then consumer permission is not required unless the text
message also authorises the charge. The intent to send a text message must be detailed in the terms of the service
MT Method: The App requests the MSISDN from the consumer, which is passed to the API who sends a unique verification code to the MSISDN via a freeto-receive MT message. The App automatically verifies the MT message, extracts the verification code and transfers this code to the API along with the
charging request, thereby completing the verification loop
The Payment Library is required to provide for error situations such as messages not sending, messages not being received, payment errors etc, using guidelines
set out in Payforit Consumer Experience Flows previously.
Marketing to the MSISDN is only allowed if the Marketing opt-in tick box was presented to the consumer at the time that they submitted their MSISDN (MT flow)
or their MSISDN was presented to the consumer along with the Marketing opt-in tick box when MSISDN pass through or MO methods were used.

Page 94 of 143
Click to go
back to
Contents
Page
PAYFORIT RULES SECTIONS

This section of the Payforit Scheme Rules contains the detailed information that APIs and Merchants need to understand and comply with when running and using
the Payforit Scheme. It is essential that the Payforit Rules are followed without exception and any requirements to deviate from the rules will need written
authorisation from the PFI MG.
The rules section covers these topics:
Section A - Payforit and Statutory Regulation: Discusses current regulations that affect Payforit
Section B - Breach of Payforit Scheme Rules: Discusses the consequences of a breach of the scheme rules
Section C - Transaction Rules: Covers in detail, the processes involved in the delivery of each of the Consumer Experience Flows
Section D - Style Rules: Covers in detail, style of language, screen presentation, buttons and logos
Section E - Text Message Mandated Language: Details each of the text messages that will be sent to a consumer during or after their usage of Payforit
Section F Audit Log Requirements: Covers the detailed information that is required to be held for audit purposes
Section G Customer Service Requirements: Covers the standards for Customer Service expected as part of the Payforit Scheme
Section H Payforit Management Group: Details how APIs, Payment Libraries and Merchants can engage with the PFI MG

Page 95 of 143
Click to go
back to
Contents
Page
SECTION A - PAYFORIT AND STATUTORY REGULATION

Payforit provides consumers with absolute pricing clarity and by selecting Buy Now (etc.) gives positive consent to charging via the API working under contract
to each MNO.
PhonepayPlus (PPP) who are the agent for the Regulator Ofcom, (who regulate telecommunication services in the UK), have deemed that the Payforit Scheme falls
under statutory premium rate regulation and therefore must comply with the premium rate regulators published code of practice (Code). For current regulation
go to the PPP Code of Practice at www.code.phonepayplus.org.uk
PPP issued the following statement in June 2013 for Payforit regulation. Please check http://www.phonepayplus.org.uk/For-Business/Code-and-Help/CodeCompliance-Updates/Statment-on-the-regulation-of-Payforit.aspx
Payforit APIs and Merchants are also bound by all applicable UK and EU laws and regulations such as (this is not intended to be an exhaustive list); Data Protection
Act 1998, Privacy and Electronic Communications (EC Directive) Regulations 2003 and Guidance notes for marketers issued by the Office of the Information
Commissioner, EU cookie laws, consumer protection laws related to the sale and supply of goods and services including The Consumer Protection (Distance
Selling) Regulation 2000, UK VAT laws, relevant advertising codes (CAP code) and the guidance of the Advertising Standards Association. For Gambling Operators
this includes a remote gambling software licence issued by the United Kingdom Gambling Commission or a licence issued by the Gambling Commission (or its
equivalent) in an approved territory, Compliance with the Merchants Gambling Commission (or its equivalent) Licence Conditions and Codes of Practice (or their
equivalent), hold a PhonepayPlus Gambling Prior Permission licence.

Page 96 of 143
Click to go
back to
Contents
Page
SECTION B - BREACH OF PAYFORIT SCHEME RULES

The Payforit Scheme Rules are developed jointly by the UK MNOs to ensure a consistent payment framework for Merchants, APIs and consumers. The
requirement to comply with the Scheme Rules and the circumstances as to when they should be applied is governed independently by each MNO under their
contractual terms with the APIs.
The Payforit Scheme is subject to the standard cross-network Red and Yellow Card Process available from www.short-codes.com.
APIs operating the Payforit Scheme must follow these Payforit Scheme Rules. To the extent if APIs have any feedback on the content of the rules, they may
provide comments to the PFI MG. The PFI MG welcomes feedback from industry participants concerning the operation of the Scheme or its rules so that they can
achieve their objective of consumer protection and a positive user experience. Contact details can be found at Payforit.org.
The respective MNOs, under their individual (confidential) contractual arrangements with APIs or Merchants, may decide to incorporate some or all of the
following, which can be restored where the issues are objectively remedied:
Review an APIs accreditation status

Take disciplinary actions against the API which may include financial penalties
Remove the accreditation of an API and prevent any further access to the MNOs billing capabilities
Apply a restriction on a Merchant operating Payforit Single Click without removing the ability to operate Payforit
Apply a restriction on a Merchant from operating under the Payforit Scheme
REVISIONS TO PAYFORIT
From time to time, MNOs will update the Payforit Scheme Rules either to enhance features available for Merchants, to provide greater clarity of a Scheme rule if
clarity is needed or to make adjustments based on changes in regulatory or operating environments.
All UK Payforit documentation and supporting assets are stored on Payforit.org.

Page 97 of 143
Click to go
back to
Contents
Page
SECTION C - TRANSACTION RULES

This section covers the detailed processing of screens, displays, charging, and background technical processing of each of the Payforit Consumer Experience Flows.
1. PAYFORIT SESSION
1.1.
1.2.
1.3.
1.4.
1.5.
Create a unique session ID at the entry point to each Payforit request.

Retain the same session ID for all navigation within one session.
Log the session ID as charged when the consumer is billed.
Check the billed status of each session before each billing request to ensure the MSISDN has not been charged previously.
Charge the MSISDN only after the robust verification requirements of each billing option have been met. MSISDN must not be recorded before sale is
made.
1.6. Charge the MSISDN only once per session.
1.7. Every Charge requires an immediate text receipt. See Section E - Text Message Mandated Language for text messages.
1.8. If the API detects that a tablet is not able to support shortcode SMS no service should be offered that requires content delivery via shortcode, opt-out to a
shortcode, and SMS receipt message (eg receipt reminder, SMS subscription acknowledgement etc). BUT if it is a URL based service it is permissible but
all reminders from shortcode SMS must go by email
2. SUBSCRIPTION AND SERVICE TRANSACTIONS

2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
API must send a freeto-consumer subscription initiation receipt message (text or email) once the consumer has agreed to the subscription by pressing
the Subscribe Now button. See Section E - Text Message Mandated Language for text messages.
Merchant must supply consumer with their product or service immediately after purchase completion and successful billing.
API must send free-to-consumer subscription reminder text (or email) messages every month or every 20 (including VAT), whichever happens first.
API must include subscription opt-out instructions as detailed in Section E - Text Message Mandated Language.
API must support the STOP command and the shortcode to which it is sent.
If API uses another shortcode to effect billing for Subscription, then this must also support the STOP command to opt-out of subscription.
API must charge consumer for Subscriptions triggered by that API only. (This is does not preclude auditable service migration to a new API).
API must ensure that billing requests to MNOs are for valid, active subscriptions and services only.

Page 98 of 143
3. ALL MT AND HYBRID BASED CONSUMER EXPERIENCE FLOWS

3.1.
Send pricing information in all text messages sent to the consumer, except service delivery text messages. See Section E - Text Message Mandated
Language.
3.2. Send the freeto-consumer purchase verification code text message to the MSISDN entered by the consumer.
3.3. Ensure the purchase verification code expires within 15 minutes of being sent.
3.4. Switch the consumer to a MO flow (if supported by API) after three unsuccessful attempts to enter the purchase verification code.
3.5. If MO flow not supported by API, abandon the transaction after three unsuccessful attempts to enter the purchase verification code.
3.6. Ensure previous purchase verification codes expire and are invalid for authentication if the consumer requests an additional purchase verification code
(APIs must cycle through a minimum of 5,000 purchase verification codes).
3.7. Ensure purchase verification codes cannot opt the consumer into a different active service (i.e., codes misspelled accidentally must not match the optin for another active service on the same shortcode).
3.8. Include, optionally, a URL in the purchase verification code text message for Mobile or Mobile Embed flows that the consumer may click to complete
purchase.
3.9. Limitations for the URL included in the MT message are;
3.9.1.URL may be clicked only within 15 minutes of the message being sent.
3.9.2.URL must enforce no more than one charge per click.
3.9.3.URL must not identify the consumer MSISDN directly; a MSISDN alias must be used.
3.9.4.URL, once clicked, must take the consumer to the API payment success screen or to the Merchants delivery of the purchased product.
3.10. Charge the MSISDN and deliver product if the correct purchase verification code is entered within 15 minutes.
3.11. Charge only the MSISDN from which the purchase verification code originated and terminated.
3.12. A dropbox for the consumer to select their own network can be provided.
4. MT- MO HYBRID CONSUMER EXPERIENCE FLOWS

4.1.
4.2.
4.3.
4.4.
4.5.
Use a unique verification code that will link the Payforit session with the MO message.
Charge the MSISDN only if it responds with the keyword within 15 minutes.
Expire verification code after 15 minutes and reject transactions that are using expired codes.
Ensure the keyword is alphanumeric, with at least one character.
Ignore additional keywords sent by the consumer after the verification keyword.

Page 99 of 143
Click to go
back to
Contents
Page
5. MO CONSUMER EXPERIENCE FLOWS

5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
5.7.
Use a unique verification keyword that will link the Payforit session with the MO message.
Check for a text message every 10 seconds, and redirect if a text message is received.
Use no generic keywords (e.g. JOIN, YES) in an MO flow because they cannot be linked robustly to the specific Payforit session; use no keywords that
might offend.
Link the consumer back to the payment success page or Merchant site for mobile and mobile embed for HTML5 Consumer Experience Flow options
within text message receipts. If the Merchant site cannot support re-entry via a link then the MO method may not be used.
Direct the consumer to a payment failure screen, page, or iFrame with an appropriate error description if they are active and have failed to send a text
message.
Use standard rate shortcodes for all MO code screens, pages, or iFrames. Long numbers may not be used. If there are any chargeable messages then
the consumer must consent to the charge. If the shortcode is zero rated, then consumer permission is not required unless the text message also
authorises the charge. The intent to send a text message must be detailed in the terms of the service.
Redirect optionally, to the payment failure screen if the API fails to receive the purchase verification code text message after 15 minutes.
6. PAYFORIT SINGLE CLICK

6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
6.8.
The Web Payforit Single Click Consumer Experience Flow is only available for sites that require the consumer to log in to the service prior to purchase
and must include the following components:
6.1.1. Information transfer will be needed to the API from the Merchant to enable the API to associate the Login with the MSISDN
6.1.2. The login shall expire within one hour since the last action on the Merchant site.
6.1.3. If MSISDN is transferred by the consumers mobile network, then the web login requirement is void.
6.1.4. The association between login and MSISDN must be renewed after 90 days have elapsed to protect against MSISDN being transferred to
another consumer.
Prompt the consumer to renew their Payforit Single Click opt-in after having spent 30, including VAT, with a single Merchant or on the expiry of 90
days since the consumers original Payforit Single Click opt-in or Re-opt-in, whichever occurs first.
Prompt the consumer to renew their Payforit Single Click opt-in when the API has detected a switch to another MNO.
Send a free-to-consumer text message to the MSISDN within 15 minutes after the last Payforit Single Click purchase containing a receipt for either a
single purchase or an aggregated receipt for multiple Payforit Single Click purchases (see Section E - Text Message Mandated Language for message
construction).
Operate an API-controlled consumer helpline with Merchant-specific call logging detailing MSISDN, call date and time, and call duration (this helpline
may be an API IVR line redirecting to the Merchant).
Identify the consumer device with an Alias that is an identifier and that does not contain the consumer MSISDN.
Encrypt the Alias to avoid cloning and do not release information to Merchants on Alias encryption methods.
Payforit Single Click may be used for one-off purchases and donations only. It CANNOT be used for subscriptions.

Page 100 of 143
Click to go
back to
Contents
Page
6.9.
6.10.
6.11.
6.12.
The Payforit Single Click button served to the Merchants service remains linked to the consumer MSISDN and may remain valid for a single use only.
The Payforit Single Click button must be made invalid if not clicked within one hour during mobile Consumer Experience Flows.
Spend limit: the API must prompt the consumer to renew the Payforit Single Click opt-in after spending 30.
Time limit: the API must prompt the consumer to renew the Payforit Single Click opt-in 90 days after original opt-in.

Page 101 of 143
Click to go
back to
Contents
Page
7. ENHANCED PURCHASE FLOW

7.1.
All Enhanced Purchase Flow services require the consumer to proactively accept the Enhanced Purchase Flow terms terms of purchase via the Entry
Screen (Enhanced Purchase Flow Entry):
7.1.1. The enter button must be clicked before the consumer is served the content and no content can be accessed until this is done
7.1.2. For clarity the content should remain behind a translucent screen until the enter button has been clicked. The translucent screen should be a
black overlay that is at least 50% black (where 100% black would mean that the content would not be visible at all). The underlying content
page should not be designed so as to distort the message or intent of the Entry Screen
7.1.3. Consumers may scroll and browse but the entire floating accept header must always be visible
7.1.4. The consumer must be presented with the enter process every 24 hours or calendar day
7.1.5. If, once in the content selection area, the consumer unticks the pre-ticked box they will be directed through a standard PFI flow
7.2. The API must record all Customer Service calls (in line with all relevant regulations) received in addition to retaining call logs, as required in the Payforit
4 scheme rules. All call recordings must be analysed by the API (i.e. by listening to the recording) on a weekly basis for any consumer grievances. All call
recordings must be retained for a minimum of 12 months. If a consumer enquiry has been escalated, all calls must be retained for six months after the
case has been closed.
7.3. If the quantity of calls relative to the total number of service users increases by more than 10% in a 7 day period then the API must suspend the service
until the cause is identified and rectified.
7.4. No one service may bill more than 30 in a 24 hour period (or calendar day to APIs preference). It is recommended that the API send the following free
to user message to the consumer for each and every 100 spent in a calendar month (from: Payforit). This must be sent using the same network for
internal audit trail purposes. Message: FreeMsg: You have spent [month total] with [merchant] this month. This is not a subscription service and will
appear as [descriptor] on your bill.
7.5. To keep a full record of the users consent for the service, the API must retain the HTML source code of every merchant page the consumer interacts
with for 24 months. For clarification, this means the HTML and CSS for each page impression and image and not a template version of a page. The API
does NOT need to store the purchased content.
7.6. Each page must have a time stamp to log the time spent navigating the site and a record of which link on a page was selected to access the next page.
7.7. The API is not permitted to pass the MSISDN to the merchant under any scenario and the merchant must agree to forfeit all rights to the MSISDN when
using this service. This includes the MSISDN for Customer Service and marketing purposes.
7.8. If an age verification process is carried out on entry to the site that involves the use of a MSISDN it must be done by the API and not the merchant.
7.9. The API may pass the merchant an alias to identify the consumer for Customer Service purposes and the merchant may send appropriate marketing
communication to the consumer (when permission has been granted) through the API (or other APIs). It is the sending. It is the APIs responsibility to
ensure all marketing opt out requests are handled appropriately.
7.10. The consumer may only be charged the full tariff amount displayed on screen and not multiple amounts to reach the price point advertised, unless this
has been permitted by the network operators billing policy. Any re-tries of a transaction that have failed for insufficient credit or any other reason must
conform to the network operator re-try policy.

Page 102 of 143
Click to go
back to
Contents
Page
7.11. Only the API is allowed to control pricing information and chargeable links on a page. The API must verify all information appears correctly before
displaying the page to the consumer.
7.12. It is the APIs responsibility to ensure that hyperlinks that incur a charge cannot be accidently clicked when the consumer clicks a non-chargeable link.
Additionally, the API must ensure the consumer is only charged ONCE for each item and that they cannot be charged for something already purchased.
7.13. When a consumer makes a purchase using the selection screen (Enhanced Purchase Flow Selection Screen) where the API can offer multiple prices, all
subsequent Payforit Enhanced Purchase Flow purchases on the content delivery screen (Enhanced Purchase Flow Content Delivery Screen) must be
the same price, or less, than the purchase made on the selection screen and must always be above the fold. If the merchant wants to offer the
consumer a product at a different price (higher or lower), the consumer should return to a selection screen to make a new selection at the different
(higher or lower) price, after which subsequent Payforit Single Click purchases must be at the same price (or lower) until they return to the selection
screen. Pricing consistency is a requirement to reduce the impact of bill shock to consumers when buying multiple products but allows APIs to price
services as required.
7.14. When the API offers multiple, time limited, purchases such as via paywalls, the minimum period that can be offered is 24 hours and where it is an
experience good the 10 minute cancellation rule (7.18) applies.
7.15. To ensure an indisputable audit trail, the consumer may only pass through one API MSISDN white listed URL between viewing an advert (e.g. a banner
advert on a third party site or a pay per click advert) and visiting a selection screen controlled by the API. Any exception to this must be received in
writing from the PFI MG.
7.16. The API must control the serving of all HTML, CSS, and image content for all screens served directly to the consumer (including the selection and
delivery screen). The merchant may not serve any screen that contains any chargeable actions to the consumer outside of the control of the API.
Additionally all screens controlled by the API must have the source code retained as per Audit Requirements (see Section F Audit Log requirements)
7.17. The API must complete the Payforit certification assessment before using Enhanced Purchase Flow.
7.18. The API must offer a 10 minute trial period for each content item selected by suspending billing for that item until the expiry of 10 minutes and must
also display the text: This mobile will be charged (price) because a selection was made on the previous screen. If you are not satisfied, you may cancel
this charge by clicking here before [time] The cancellation rule only applies to experience goods. An experience good is a product or service where
product characteristics, such as quality or price, are difficult to observe in advance, but these characteristics can be ascertained upon consumption.
7.19. If the consumer elects to cancel the charge, the current and all prior suspended billing transactions within the last 10 minutes are cancelled. The receipt
for any purchases successfully charged is aggregated and sent immediately.
7.20. If the consumer elects to cancel the charge, then the API can (optionally) prevent the consumer from making subsequent purchases. In this case, the API
must route the consumer away from the service
7.21. MO can be done at the point of purchase for In-App billing
7.22. IVRs can be used to improve the user experience and to enable more rapid processing.
7.23. MSISDN can be entered as part of the pin flow for tablets and iPads to enable transactions from these devices.
7.24. Competitions:
7.24.1. The consumer must be told how many times they have entered (each being a single purchase) and be prevented from being charged again.
7.24.2. Immediate billing is preferred.
7.24.3. It must be indicated that it is not a subscription service.

Page 103 of 143
8. GAMBLING PURCHASE FLOW

8.1.
8.2.
8.3.
8.4.
8.5.
8.6.
8.7.
8.8.
8.9.
8.10.
8.11.
8.12.
8.13.
The merchant must conduct sufficient age verification when a new user registers with them in accordance with PhonepayPlus gambling prior
permission guidelines and the requirements for holding a UK gambling licence. With this in place, the merchant can bypass the MNOs age verification
process.
The API must have visibility of the user opt in when they choose to deposit via Payforit for the first time. The merchant can either request a mobile
originated SMS (MO) into a shortcode belonging to the API or send the user a web link via SMS that redirects via the API to enable Payforit deposits.
Merchants who are certified gambling operators are allowed to place pricing information and chargeable links on to a page behind secure login. This
information can be displayed to suit the merchant but both the API and the merchant must verify all information appears correctly before displaying
the page to the customer.
It is the API and merchants responsibility to ensure that the consumer is informed of the amount to be charged and that all chargeable actions are
displayed clearly and in accordance with PhonepayPlus Code of Practice. Additionally, the API must ensure the consumer is only charged once for each
deposit.
The consumer must always see the purchase screen where the merchant can offer multiple deposit options. This applies to initial and subsequent
Payforit purchases
No one service may bill more than 30 in a 24 hour period, as aligned with the PhonepayPlus Gambling Prior Permission
The consumer may only be charged the full tariff amount displayed on the screen and not multiple amounts to reach the price point advertised, unless
this has been permitted by the network operators billing policy. Any re-tries of a transaction that have failed for insufficient credit or any other reason
must conform to the network operator re-try policy.
In the Gambling Purchase Flow the pricing box can be made to be a drop down box allowing multiple deposit options up to a maximum of 30.00.
The API must record all customer care calls, in line with any relevant laws applicable, and emails received in addition to retaining customer care
statistics. All care statistics must be analysed by the API on a regular basis for any concerning trends. All call recordings must be retained for a
minimum of 3 months. If a consumer enquiry has been escalated all calls must be retained for 6 months after the case has been closed.
If the quantity of customer care enquiries relative to the total number of service users increases by more than 10% in a 7 day period then the API must
suspend the service until the cause is identified and rectified.
If a user has been dormant on Payforit in relation to the services provided by the merchant for 3 months or more the merchant must request an MO
from that user which goes via their API. Only after this MO has been received can the merchant bill the user via Payforit again.
Customers must be told they cannot re-credit any winnings from their gambling account to their mobile account.
The API must notify the Payforit Management Group two weeks in advance of enabling a merchant to utilise the Gambling Purchase Flow.

Page 104 of 143
Click to go
back to
Contents
Page
9. DOUBLE OPT-IN FLOW

9.1.
9.2.
9.3.
9.4.
9.5.
9.6.
9.7.
9.8.
9.9.
9.10.
9.11.
9.12.
9.13.
9.14.
The API must record all Customer Service calls (in line with all relevant regulations) received in addition to retaining call logs, as required in the Payforit
4 scheme rules. All call recordings must be analysed by the API (i.e. by listening to the recording) on a weekly basis for any consumer grievances and be
immediately investigated with the merchant.
All call recordings must be retained for a minimum of 12 months. If a consumer enquiry has been escalated, all calls must be retained for six months
after the case has been closed.
If the quantity of calls relative to the total number of service users increases by more than 10% in a 7 day period then the API must suspend the service
until the cause is identified and rectified.
Consumers must not be charged more than 30 per 24 hours or calendar day as nominated by the API for all services consumed through a single
merchants service.
It is recommended that the API send the following free to user message to the consumer for each and every 100 spent in a calendar month (from:
Payforit). This must be sent using the same network for internal audit trail purposes. Message: FreeMsg: You have spent [month total] with
[merchant] this month. This is not a subscription service and will appear as [descriptor] on your bill.
To keep a full record of the users consent for the service, the API must retain the HTML source code of every merchant page the consumer interacts
with for 24 months. For clarification, this means the HTML and CSS for each page impression and image and not a template version of a page. The API
does NOT need to store the purchased content.
Each page must have a time stamp to log the time visited and a record of which purchase button on a page was selected to initiate a purchase
The API is not permitted to pass the MSISDN to the merchant under any scenario and the merchant must agree to forfeit all rights to the MSISDN when
using this service. This includes the MSISDN for Customer Service and marketing purposes. MSISDNs can be submitted to the Merchant to resolve a one
on one customer care contact.
The API may pass the merchant an alias to identify the consumer for Customer Service purposes and the merchant may send appropriate marketing
communication to the consumer (when permission has been granted) through the API. It is the APIs responsibility to ensure all marketing opt out
requests are handled appropriately.
If an age verification process is carried out on entry to the site that involves the use of a MSISDN it must be done by the API and not the merchant.
(Standard MNO AV policies apply)
The consumer may only be charged the full tariff amount displayed on screen and not multiple amounts to reach the price point advertised, unless this
has been permitted by the network operators billing policy. Any re-tries of a transaction that have failed for insufficient credit or any other reason must
conform to the network operator re-try policy.
Only the API is allowed to place Purchase Buttons on a page and all parameters must be encrypted to ensure robust verification.
For time-based access, the API must ensure the consumer is only charged ONCE and that they cannot be charged for access already purchased and not
yet expired.
When the API offers time-based access, the minimum period that can be offered is 24 hours.

Page 105 of 143
9.15. To ensure an indisputable audit trail, the consumer may only pass through one API MSISDN white listed URL between viewing an advert (e.g. a banner
advert on a third party site or a pay per click advert) and visiting a selection screen controlled by the API. Any exception to this must be received in
writing from the PFI MG.
9.16. The API must control the serving of all HTML and CSS content for all screens served directly to the consumer (including the selection and delivery
screen). The merchant may not serve any screen that contains any chargeable actions to the consumer outside of the control of the API. Additionally all
screens controlled by the API must have the source code retained for 24 months as per Audit Requirements (see Section F Audit Log requirements)
9.17. The API must complete the Payforit certification assessment before using Double Opt-In Payments Flow.
9.18. The API must put an exit link on the page to allow the consumer to safely exit the page without incurring a charge.
9.19. The API must offer a 10 minute trial period for any service containing sexual adult visual content by suspending billing for that item until the expiry of 10
minutes and must also display the text: This mobile will be charged (price) because a selection was made on the previous screen. If you are not
satisfied, you may cancel this charge by clicking here before [time]. This must be placed on a page hosted by the API and shown to the consumer
immediately after the purchase has taken place.
9.20. If the consumer elects to cancel the charge, the current and all prior suspended billing transactions within the last 10 minutes are cancelled. The receipt
for any purchases successfully charged is aggregated and sent immediately.
9.21. If the consumer elects to cancel the charge, then the API can (optionally) prevent the consumer from making subsequent purchases. In this case, the API
must route the consumer away from the service
9.22. If the consumer is using a wifi connection then an MO can be received instead of clicking a purchase button to improve the user experience and to
enable better transaction processing. The MO must be uniquely and robustly linked to the consumers browsing session.
9.23. Recurring Payments
9.23.1. The service may offer a recurring payment option of weekly or monthly frequency and must abide by PhonepayPlus requirements for services
charging over 4.50 per week
9.23.2. The service may have an initial free period before charging commences. When a free period is used the welcome message should be sent
immediately instead of a receipt message
9.23.3. The API must send a welcome message to the consumer immediately
9.23.4. The API must send a reminder message for every 20 billed or one month whichever is soonest
9.23.5. The API must host the shortcode used for the STOP command and the API must process any STOP requests immediately
9.23.6. Permitted evidence for robust service consumption is
9.23.6.1. The API detecting a consumer logging into a site using a username with a password that is not prefilled. This detection may take place
using an API hosted tracking pixel providing the process is robust and tamperproof. For the avoidance of doubt, the user may request a new
password and access via this method without re-entering the password.
9.23.6.2. The consumer being sent a text message which clearly identifies the service and notable characteristics and the API logging the user
responding to the text message by an MO message.
9.23.6.3. The consumer engaging via a telephone call provided that the API records the call and the consumer performs a positive action to consent
to continued usage of the service.

Page 106 of 143
10. ERROR DESCRIPTIONS

10.1. APIs must include, as a minimum, the error description language on every payment failure screen, page or iFrame.
10.2. The same potential errors apply for all MNOs, but some error descriptions vary slightly between Three and the other MNOs.
10.3. Error Description Language for Three based on error code returned;
10.3.1. Adult services bar: This service is restricted to users 18 and older. If you are 18 or older, access http://mobile.three.co.uk/misc/pin/blocked
party to verify your age.
10.3.2. General error: Service temporarily unavailable; try again later.
10.3.3. Insufficient Funds Web: Top up your mobile phone account by accessing www.three.co.uk/My3 now.
10.3.4. Insufficient Funds Handset: Top up your mobile phone account by accessing http:\\mobile.three.co.uk/sdf/bmmy3 now.
10.3.5. Monthly Spend Limit Reached: Sorry, you've reached your monthly spending limit on charge-to-mobile services which providers have to
protect their customers. You won't be able to charge this kind of service to your bill again until next month.
10.3.6. Daily Spend Limit Reached: Sorry, you've reached your daily spending limit on charge-to-mobile services which providers have to protect their
customers. You won't be able to charge this kind of service to your bill again until tomorrow.
10.3.7. MO flow when text not received: Text message not yet received. Click Retry Payment.
10.3.8. Services bar: Premium rate services are unavailable on your account. Access www.three.co.uk/My3 now for more information.
10.4. Error Description Language for O2, Orange, T-Mobile, & Vodafone;
10.4.1. Adult services bar: This service is restricted to users 18 and older. If you are 18 or older, access [MNO contact number] to verify your age.
10.4.2. General error: Service temporarily unavailable; try again later.
10.4.3. Insufficient Funds: Top up your mobile phone account by accessing [MNO contact number] now.
10.4.4. Monthly Spend Limit Reached: Sorry, you've reached your monthly spending limit on charge-to-mobile services which providers have to
protect their customers. You won't be able to charge this kind of service to your bill again until next month.
10.4.5. Daily Spend Limit Reached: Sorry, you've reached your daily spending limit on charge-to-mobile services which providers have to protect their
customers. You won't be able to charge this kind of service to your bill again until tomorrow.
10.4.6. MO flow when text not received: Text message not yet received. Click Retry Payment.
10.4.7. Services bar: Premium rate services are unavailable on your account. Access [MNO contact number] now for more information.
10.5. Shown with every error description: To contact your mobile phone company, please call [MNO contact number] directly from your mobile phone.
10.5.1. MNO Contact numbers are: O2: 202 (contract consumers) or 4445 (prepay consumers), Orange: 150 (contract consumers) or 450 (prepay
consumers), T-Mobile: 150, Vodafone: 191.
10.6. Error Description Language for Gambling Purchase Flow: We were not able to apply this charge to your mobile account. Please contact our customer
care team on XXXXXXXXXXX or try to deposit using another payment option
11. TEXT RECEIPTS

Page 107 of 143
Click to go
back to
Contents
Page
11.1. See Section E - Text Message Mandated Language for message construction.
11.2. Send a text receipt, via the consumers network, for all successful transactions immediately except for Payforit Single Click. If an alternate mobile
number is provided the receipt message must be sent from the network of that number.
11.3. When API detects that the user is connected via a device that cannot receive SMS, the API must capture and validate the consumer email address prior
to proceeding to the purchase call to action and send an email receipt for all successful payment transactions. The email address can be stored by the
API so that the user doesnt need to re-enter on each purchase.
11.4. For Single Click transactions, send an aggregated receipt (if consumer has purchased multiple items) for all transactions within 15 minute from the
completion of the last transaction.
11.5. Link the consumer back to the payment success screen, page, iFrame or Merchant Service for all mobile payment flows from within the text message
receipt.
11.6. The sender address should be Receipt unless this is not appropriate eg the consumer is in a subscription service, in which case it should be a
shortcode. It should never be from Payforit.
12. MSISDN
12.1. Obtain the MSISDN only from the consumers mobile network, from the consumer directly or from an inbound text message to the API shortcode. APIs
must validate the MSISDN through one of the Payforit Consumer Experience Flows.
12.2. Only pass the MSISDN to the Merchant under contract solely for the purposes of;
12.2.1. Product or service delivery;
12.2.2. Customer Service;
12.2.3. Marketing only if the Marketing opt-in tick box remains ticked when the Payforit Consumer Experience Flow is finished.
12.3. In all other cases, APIs must safeguard consumer MSISDNs from Merchants and other APIs.
12.4. Merchants are not permitted to use consumer MSISDNs that have been passed to them by the API for subsequent billing purposes (i.e. via PSMS).
12.5. Merchants are not permitted to use consumer MSISDNs that have been passed to them by the API for any other purpose that would contravene Data
Protection Laws, PhonepayPlus Code or individual MNO requirements.
13. ALTERNATE MOBILE PROCESSING

13.1. The Optional Alternate Mobile link in MSISDN Pass-Through Consumer Experience Flow is designed to allow the consumer to charge another mobile
account for the service being consumed on the original device (e.g. a parent paying for a service their child is using).
13.2. Invoke the MT or MT-MO Hybrid flows only (not MO) when this option is selected to gain the new MSISDN from the consumer and verify the MSISDN
using the MT or Hybrid Payforit flows.
13.3. Send the text receipt to the MSISDN entered.
13.4. Ensure that the Merchant service can be delivered from the Payforit Success Page and is not dependant on the link in the text receipt (as this would
have gone to another device).

Page 108 of 143
Click to go
back to
Contents
Page
13.5. Do not use Aliases in association with this MSISDN.
14. SCREEN DISPLAY PROCESSING

14.1. All Payforit Payment screens or buttons served into the Merchant environment (iFrames, embed, in-App etc) must be free from any Merchant display
items that would position over the Payment frames. They must be free from any moving, flashing or other mechanisms that would be considered to
obfuscate the display, to prevent or distract the consumer from reading the information. All pricing must be shown in the format detailed in Section D Style Rules.
14.2. Pricing notification must not be deliberately complex. E.g. 2*2 per 3 days when 4 per 3 days is adequate.
14.3. The name of the product / service being purchased must be consistent with the product / service selected by the consumer on the Merchant site.
14.4. When the Payforit Logo is clicked by the consumer, the API will present the About Payforit screen.
14.5. Call to Action button can only contain the following words based on the Merchant Service and the Consumer Experience Flow
14.5.1. Buy Now: For single (one-off) purchases.
14.5.2. Subscribe Now: For subscription services.
14.5.3. Donate Now: For Charity Donations.
14.5.4. Deposit Now: For Gambling Purchases
14.5.5. Continue: Where the consumer is entering their MSISDN in MT or Hybrid Flow or is using the MO flow except for Embed.
14.5.6. Next: Where the consumer is entering their MSISDN in Embed MT or Hybrid Flow or is using the Embed MO flow.
14.5.7. Retry Payment: Where the payment has failed and the consumer wishes to retry.
14.6. The Merchant Name (when using an unbranded layout), must be the name of the Merchant that is recognisable from the prior part of the consumer
journey.
14.7. The Dont know your mobile number? link will switch the Consumer Experience Flow from Mobile MSISDN through MT to Mobile MSISDN through
MO flow. This is optional for the API to implement.
14.8. The Cancel Purchase Link must take the consumer back to the Merchant Screen with the Merchant advised that the consumer has cancelled so that
correct business logic can be deployed.
14.9. The Need Help? Section must contain the Merchant or API support details. The phone number can use click to call Smartphone function. The email
address can use click to email" Smartphone function.
14.10. The Need Help? section links should behave as follows;
14.10.1. Should be above the fold of the screen
14.10.2. The links for Merchant and Payforit terms must be separate.
14.10.3. The Payforit link will open an API served About Payforit page.
14.11. Tick-Boxes as presented on Optional Success Pages rules are:
14.11.1. Pre-tick, optionally, the Marketing opt-in tick-box. Please note: All Networks highly recommend as best practice for the Marketing opt-in tickbox to be shown as un-ticked.

Page 109 of 143
Click to go
back to
Contents
Page
14.11.2. Pre-tick, optionally, the Single Click opt-in tick-box. Please note: All Networks highly recommend as best practice for the Single Click opt-in tickbox to be shown as un-ticked.
14.12. If a MO flow is used, the Single Click opt-in tick-box may not be pre-ticked if the screen automatically redirects the consumer after their MO text
message has been received.
15. PAYMENT FAILURE

15.1. If the consumer selects the Retry Payment Call to Action, then they must be returned to the Payment Screen to reconfirm their purchase. The API
should not attempt a billing retry on the network.

Page 110 of 143
Click to go
back to
Contents
Page
SECTION D - STYLE RULES

1. PRICING NOTIFICATION FIELD
1.1.
The pricing notification field (see Common Screen items) must follow these rules for the combined display of Product (or service) and Price.
Type of Transaction
One-off payment
Buy < product / service > for <Price>
One-off charity donation
Donate <Price>
Charity subscription
Donate <Price> per <Billing Frequency>
Standard subscription
Subscribe to < product / service > for <Price> per

<Billing Frequency>
Subscription with initial free period
Subscribe to < product / service > free for <Period>

and then be charged <Price> per <Billing Frequency>
Subscription with initial charge
Subscribe to < product / service > for an initial charge

of <Initial Charge> plus <Price> per <Billing
Frequency>
Gambling Purchase
Deposit <Price>

Page 111 of 143
Click to go
back to
Contents
Page
2. MERCHANT NAME
2.1.
The Merchant Name Field (see Common Screen items) on unbranded payment flows, must;
2.1.1. Contain the name of the Merchant, recognisable from the prior part of the consumers journey.
2.1.2. Contain the word From when the transaction is a purchase E.g. From Factory Direct.
2.1.3. Contain the word To when the transaction is a donation. To Children in Need.
2.2. The name of the Merchant must be the same name used in text receipts.
3. PRICE
3.1.
The price of the product or service in the Pricing Display field must be presented in pounds sterling using the principles;
3.1.1. If the price is 99p or lower present the pricing in pence e.g. 69p.
3.1.2. If the price is above 99p use the sign (symbol).
3.1.3. If the price is in pounds only (e.g. 1), pricing can be presented as x or x.00 (e.g. 3 or 3.00).
3.1.4. If the pricing is pounds and pence, pricing must be presented as x.xx e.g. 3.99.
3.1.5. Do not allow pricing display that could be misleading e.g. 4*2 instead of 8.
3.2. In the Gambling Purchase Flow the pricing box can be made to be a drop down box allowing multiple deposit options up to a maximum of 30.00.
4. PAYMENT RECEIVED NOTIFICATION

4.1.
The Payment Received Notification Field (see Common Screen items) must state;
4.1.1. Youve paid <Price> for one-off payments.
4.1.2. Youve donated <Price> for donations.
4.1.3. Your subscription <Price> has been set up and will continue until you text STOP to <Shortcode> for subscription services.
4.1.4. You have deposited <Price> and your gambling account has been credited for gambling purchases.
5. SCREENS, PAGES, IFRAMES, AND BUTTONS

5.1.
5.2.
5.3.
Follow, with no deviation (except for button colour), the screen, page, and iFrame Consumer Experience Flow design options presented in the Scheme
Rules for all Consumer Experience Flows.
Use the HTML files and CSS files supplied on Payforit.org as reference material in order to create the Consumer Experience Flows.
Serve all screen, page, and iFrames, with product and pricing information provided by Merchants.

Page 112 of 143
Click to go
back to
Contents
Page
5.4.
Present each Merchant- or MNO-branded screen, page, or iFrame consistently. If the Merchant or MNO logo is on the previous screen, it must remain
on the following screen throughout the Consumer Experience Flow.
5.5. Call to Action buttons may be presented in a different colour providing that the contrast between text and button colour is contrasting as follows;
5.5.1. Convert the dominant background colour to HSL (hue, saturation, lightness).
5.5.2. Present the text in white (#FFFFF) when the lightness is less than 50%.
5.5.3. Present the text in black (#00000) when the lightness is greater than 50%.
5.5.4. Present the text in either white or black when the lightness is exactly 50%.
5.6. A drop down box can be provided in MT flow for consumers to select their own network
6. EMBED METHOD FOR HTML5 PAYMENTS

6.1.
6.2.
6.3.
6.4.
6.5.
Present mobile HTML5 iFrames with a minimum width of 200 pixels and a minimum height of 120 pixels.
Present Web / Tablet HTML5 iFrames with a minimum width of 300 pixels and a minimum height of 200 pixels.
The frame sizes can be increased proportionally but the iFrame must not occupy more than 80% of the available screen display.
Present the embed method for HTML5 payments flow within iFrames superimposed on the Merchant screen or page.
Present the iFrame with a transparent background or a custom colour or image of the Merchants choice.
7. ENHANCED PURCHASE FLOW

7.1.
Entry Accept Screen

7.1.1. Total Header box including text and enter button must be a minimum of 15% of the screen or 68px whichever is the greater and must be static
(floating)
7.1.2. Enter button must be 50% (or 106px but no more than 60%) of the total header box. Enter button is contiguous with the rest of the header
7.1.3. Enter buttons text is white or black using the contrast ratio to determine the colour based on the buttons background colour
7.1.4. The content on the rest of the screen must be covered by a translucent shield (at least 50% black, where 100% black would mean that the content
would not be visible at all) until the enter button has been clicked and the terms accepted
7.1.5. There is no requirement for the marketing opt in box or merchants terms on the Entry Accept Screen
7.1.6. There must be an ability to exit the website from the floating header. The merchant may add a more prominent exit option on the translucent
shield if they wish.
7.2. Content Selection Header Box
7.2.1. Header lines must be at least 15px top padding and 10px space between each line
7.2.2. The header box is a minimum height of 80px, in proportion with the rest of the screen and must be static (floating)
7.2.3. The marketing opt in box is always required on the content selection page if marketing permission is requested
7.2.4. There must be an ability to exit the website from the floating header
7.2.5. If the video is streaming this must be made explicit in the header

Page 113 of 143
7.3.
Click to go
back to
Contents
Page
Pricing
7.3.1. Pricing information display must state Click to buy [and/,] will be added to this [mobiles/phone] bill as nominated by the API
7.3.2. Font size must be 12px and any additional text must be same or smaller font size and in proportion to the image
7.3.3. If different prices are shown across content selection page then all pricing information must be at least font size 15px.
7.3.4. Price must be on a black or white background only and must be made clear
7.3.5. Price must be in bold
7.3.6. Pricing text must be immediately below image unless in List Style
7.3.7. First thumbnail pricing must appear above the fold
7.4. Thumbnails
7.4.1. The design of the content thumbnail is at least 145px wide by 100px high
7.4.2. In Grid, Hero and List Styles the space between the rows should be a minimum of 3%
7.4.3. Thumbnails must be a maximum height of 500px and be centred
7.4.4. The clickable area has a maximum width of 80% of the screen and must be at least 10% screen width from either edge.
7.4.5. The clickable area has a border surrounding it to clearly highlight the selection area
7.4.6. The entire thumbnail has a border surrounding it to clearly highlight the selection area
7.4.7. No additional text/ icons allowed within the bordered area except a play icon
7.4.8. The entire bordered area is clickable to charge
7.4.9. Full width images are OK but it must present a clear (eg shaded) clickable area no wider than 80% and 500px high
7.4.10. No text on image except HD or video time length
7.4.11. Logos are permitted as long as they dont detract from the prominence of the pricing information
7.4.12. A page may have many videos on it, for example 20-30 videos, using the same thumbnail format shown in the Enhanced Purchase Flow
7.4.13. In Carousel Style the images must not be clickable to charge
7.5. Instructions
7.5.1. Instruction text (click to view your video,) must appear at the top in font size 11px
7.5.2. Instructions must be black text on white background or white text on black background
7.5.3. The call to action should not overshadow the pricing information and should be within the same thumbnail or promotional material
7.5.4. Previous and next video screens can be alongside the main picture as long as full and clear pricing is below the thumbnail
7.5.5. Carousels require scroll buttons
7.5.6. Image to watch and cancel box must appear at the top so that with the handset in landscape mode the message remains on the screen
7.5.7. Words on the page can describe next video but must not be clickable
7.5.8. In Carousel Style there must be scroll buttons (next/previous)
7.6. A page may have multiple section headers to link different content types together
7.7. Any upsell options can appear within first 800px as long as price text is and cancel option are above the fold
7.8. If the advertising for the service has any indication that some content is free (including metatags) then a link shall be provided by the API to the free
content and placed in a prominent position close to the top of the page.

Page 114 of 143
Click to go
back to
Contents
Page
7.9. In competitions there should be a holding page to address network connection delays
7.10. Banners and floaters are permitted
8. DOUBLE OPT-IN FLOW

8.1 Headerbox
8.1.1 The header box is a minimum height of 28px or 7% of the screen (whichever is greater) and is in proportion with the rest of the screen. It should
float at the top of the screen if the user scrolls the page.
8.1.2 The marketing opt in box is always required on the first page if marketing permission is requested. It may be omitted if the marketing opt in is not
permitted but the header box must remain above the minimum size.
8.2 A cancel box (for sexual adult services) must appear at the top of the screen on the page immediately following the purchase button page. This is to allow
the message to remain on the screen when the handset is in landscape mode.
8.3 If the advertising for the service has any indication that some content is free (including metatags) then a link shall be provided by the API to the free
content and placed in a prominent position above the fold.
8.4 Exit link
8.4.1 The exit link must state Click here to exit website and be prominent to the purchase button when there is only one payment option per page. If
there are multiple purchase buttons on the page then the exit link must be in the Payforit header box.
8.4.2 If the purchase button is above the fold then the exit link must also be above the fold. The exit link must be at least 30px away from the purchase
button to avoid accidental clicks.
8.4.3 The exit link must be a contrasting colour to the background of the page and at least a font size of 12px and not be obfuscated.
8.5 Purchase Button The API must ensure that
8.5.1 Only the purchase button may be clicked to provide the consumers consent to be charged
8.5.2 a purchase buttons width is not greater than 80% of the screen width and it should be positioned at least 10% away from the edge of the phones
screen this applies to the first and second opt-in buttons
8.5.3 the top and bottom border of the purchase button does not have more than 15px padding from the purchase buttons text
8.5.4 a purchase buttons background colour has a clear contrast to the background colour of the merchant site that surrounds the button
8.5.5 all text on a purchase button must be of the same font colour and style. All text must be at least font size 12px. The use of italic and underlining is
not permitted. However, the top line of text may be in bold provided it does not detract from the pricing prominence. Adjacent text, graphics and
logos must not detract from the pricing prominence.
8.5.6 a purchase buttons text is white or black using the contrast ratio to determine the colour based on the buttons background colour
8.5.7 the purchase button only contains text and no logos, images or icons

Page 115 of 143
Click to go
back to
Contents
Page
8.5.8
8.5.9
8.5.10
8.5.11
8.5.12
8.5.13
8.5.14
8.5.15
8.5.16
8.5.17
there is a clear spacing around the Purchase Button and that any adjacent images or text do not detract from the Purchase Button
the second opt-in purchase button must be a different colour to the first step opt-in purchase button and remain contrasting to the merchants
background colour that surrounds it. The second opt-in purchase buttons text colour must also use the contrast ratio to determine the colour
based on the second opt-in purchase buttons background colour
the call to action wording forming the first line of the button on both purchase buttons may be specified by the merchant but must only be one
line and not contain any obfuscation text. It must be verified and placed on the button by the API and the merchant must not have any capacity to
interfere with it.
the text on the first opt-in purchase button must start with get, buy or donate and clearly describe any terms of the purchase, for example get 7
days access. If a recurring payment option is being used then the call to action text must start with the word Join.
the second opt-in purchase button call to action should not mislead the consumer and must make it clear they need to click to confirm the
purchase, for example Enter?
the second line of the first opt in purchase button must state either Buy now for x.xx or Join now for x.xx per [week/month]. If a free period is
being offered before any recurring payments take place then this must be clearly communicated to the consumer using Join now for x.xx per
[week/month] after x [Hours | Days | Weeks].
the second line of the second opt-in purchase button must state The charge will go onto this mobile bill
the second line of text on both purchase buttons must be at least 50% of the size of the first line of text (the call to action line) immediately above
it and not less than 12px.
there must be no spacing or distortion of text between the first and second line of text
the pricing display must follow the principles set out in Section D Sub-Section 3 the actual price and sign must be in bold
9. PAYFORIT LOGO
9.1
9.2
9.3
9.4
Place the Payforit Logo as demonstrated on all Payforit Consumer Experience Flows.
Hyperlink the Payforit logo to the Payforit information screen, page, or iFrame on all Payforit screens, pages, and iFrames.
Use only master versions of the Payforit logo.
Use only the approved Payforit logo proportions for Payforit Single Click and embed method for HTML5 Consumer Experience Flows, with a width of 40
pixels and a height of 20 pixels.
9.5 Use only the approved Payforit logo proportions for all other Consumer Experience Flows presented optimally (120*60 pixels), with a minimum width of
40 pixels and a height of 20 pixels.
9.6 Apply the Payforit logo to approved product or service only, with no implied affiliations with, or endorsements of, unapproved products or services.
9.7 Surround the Payforit logo with a clear zone, as defined by the master version of the Payforit logo.
9.8 Apply the Payforit trademark to approved sites only; refrain from applying the Payforit logo to sites that violate laws or regulations.
9.9 Employ only the approved Payforit trademark, using no hyphenations, abbreviations, or acronyms.
9.10
Display the Payforit trademark in a manner that is fair, truthful, positive, and inoffensive to MNOs.
9.11
Register only the appropriate trademark as a second-level domain name, without referring to the Payforit trademark.

Page 116 of 143
Click
Clicktotogo
go
back
backtoto
Contents
Contents
Page
Page
9.12
Capitalise the letter P of Payforit, and lowercase the remaining letters.
10. MNO AND API LOGO PLACEMENT

10.1. MNO Logo only: When used, centre the MNO logo in the top part of the Web Payforit screen.
10.2. API Logo only: When used, centre the API logo in the top part of the Web Payforit screen (Not T-Mobile or
Orange Networks).
10.3. API Logo only: When used, place API logo in the Need Help? section and right align.
10.4. MNO and API Logos; When both together, centre the API logo in the top part of the Web Payforit screen and left
align the MNO logo (Not T-Mobile, Three or Orange Networks).
10.5.
10.6.
Show no logo when the consumers MNO is unknown.

Present the MNO logo when the consumers MNO is clear; however, present no logo when the consumers
MNO cannot be determined.

Page 117 of 143
10.7. Present the MNO and Payforit logos side by side on all other screens and pages (except Web Payforit).
10.8. Use no MVNO logos on Payforit screens, pages, and iFrames. If MVNO is known, show no logo on Payforit screens, pages and iFrames.
10.9.
11. MERCHANT LOGOS, SLOGANS, AND DESIGNS

11.1.
11.2.
11.3.
11.4.
11.5.
Present no Merchant logo on Payforit screens, pages, and iFrames containing products or services that might bring the Payforit logo into disrepute.
Use only logos, slogans, and designs that cannot be confused with the Payforit logo and the Payforit trademark.
Present the Merchant logo for mobile with a maximum height of 40 pixels and a maximum width of 180 pixels
Present the Merchant logo for Web with a maximum height of 40 pixels and a maximum width of 440 pixels.
Use no animation within the Merchant logo.
12. PAYFORIT SINGLE CLICK LOGO AND BUTTON

12.1. Present the Payforit Single Click button as the default button design, including price and Payforit Single Click logo.
12.2. Obtain preapproval from the Payforit Management Group for unique variations of the default Payforit Single Click button
design.
12.3. Present the Payforit logo and clear pricing information, including VAT, on all Payforit Single Click buttons.
12.4. Present the Payforit Single Click logo with a minimum height of 20 pixels and a minimum width of 40 pixels.
12.5. Present the price, Payforit Single Click logo, and optional call-to-action, no more than 30 pixels apart and with no overlapping
or touching of these components.
12.6. Present the price and optional call-to-action in a contrasting colour.
12.6.1. Convert the dominant background colour to HSL (hue, saturation, lightness).
12.6.2. Present the text in white (#FFFFF) when the lightness is less than 50%.
12.6.3. Present the text in black (#00000) when the lightness is greater than 50%.
12.6.4. Present the text in either white or black when the lightness is exactly 50%.
12.7. Present the price and optional call-to-action in a font with a minimum size of 10 pixels.

Page 118 of 143
Click to go
back to
Contents
Page
SECTION E - TEXT MESSAGE MANDATED LANGUAGE

Text messages are a requirement to clarify a Consumer Experience Flows, to invite a consumer to make a purchase, verify a consumer MSISDN and deliver a
receipt of purchase. This is to ensure that the consumer is kept fully informed during their purchasing journey. When API detects that the user is connected via a
device that cannot receive SMS text receipts, the API must capture and validate the consumer email address prior to proceeding to the purchase call to action and
send an email receipt for all successful payment transactions. The email address can be stored by the API so that the user doesnt need to re-enter on each
purchase. The table below provides a full guide to every event, transaction, and billing option that offers or requires a text message, along with correlating rules
and mandated language.
Purchase Receipt Text Messages: APIs are required to send a free-to-consumer text message receipt at the culmination of every purchase. The mandated
language and content varies between subscriptions, one-off purchases and multiple simultaneous purchases.
MSISDN Verification Code Text Message: MSISDN verification code text messages are crucial to the conclusion of an MT Consumer Experience Flow. These flows
require that APIs send a text message containing a unique code to the participating consumer, prompting them to re-enter the purchase verification code into the
Payforit Payment screen. The mandated language varies between transaction types.
Service Delivery Text Messages: APIs may send an optional service delivery text message for when a consumer leaves a payment flow for any reason without
completion (checkout abandonment). Checkout abandonment messages may not be used as a marketing instrument. Only one message should be sent. Direct the
consumer via the URL to a landing page on the Merchant site or to the start of a new Payforit session only, never to an existing purchase.
Marketing Text Messages: Once a consumer opts into marketing from the Merchant via a tick-box on the relevant Payforit screen, page, or iFrame, Merchants
and APIs on behalf of their Merchants may send them text messages for the express purpose of marketing. Marketing messages should be relevant to each
consumer and advertise products similar to ones theyve already purchased. Messages must detail a marketing opt-out facility.
Alternate Marketing Text Messages: Alternate marketing text messages are designed to bring a consumer straight from the message to a Payforit payment screen
on behalf of the Merchant to make a product or service purchase without having to go through the Merchant pages. An example of this usage is topping up an
existing account of points or credits. These can only be sent by the API to marketing opt-in consumers and may include an API URL linking to the pricing
notification screen of any Consumer Experience flow. The message must have an opt-out facility.
Message Costs: All MT messages must be free to the receiver and be routed through the consumers mobile network. All MO messages must be standard network
rate or less.
Sender Address: All MT messages must use Receipt as the sender address, except for subscription messages where a shortcode is required to enable a reply or
Hybrid flows where the MT message invites a reply to a shortcode.

Page 119 of 143
Text Messages: APIs must use specific language for each text message for each consumer event in the table below. Although some text messages are optional, all
text messages, without deviation, must include the mandated language or information shown. APIs may add no information to the mandated language.
Click to go
back to
Contents
Page
REF
EVENT
TEXT MESSAGE LANGUAGE
WHEN TO
SEND
SENDER
ADDRESS
E1
Consumer opts into subscription; mandatory delivery of free

text message receipt.
FreeMsg: Thank you for subscribing to <service name> for

<price in > per <billing frequency> from <Merchant> until
you text STOP to <shortcode>. HELP? <UK standard rate or
free helpline number>.
Immediately Receipt
E2
Consumer opts into subscription; mandatory delivery of free

subscription/spend reminder.
FreeMsg: Reminder. You are subscribed to <service name>

for <price in > per <billing frequency> from <Merchant>
until you text STOP to <shortcode>. HELP? <UK standard
rate or free helpline number>.
20 or
monthly
Receipt
E3
Consumer opts into subscription with initial free period;

mandatory delivery of free subscription opt-in text message
receipt.
FreeMsg: You are subscribed to <service name> for <price

in > per <billing frequency> from <date> unless you text
STOP to <shortcode>. HELP? <UK standard rate or free
helpline number>.
Within 15
minutes
Receipt
E4
Consumer opts into subscription with initial charge;

receipt.
FreeMsg: You are subscribed to <service name> for <initial

charge in > plus <price in > per <billing frequency> until
you text STOP to <shortcode>. HELP? <UK standard rate or
free helpline number>.
Within 15
minutes
Receipt

Page 120 of 143
Click to go
back to
Contents
Page
REF
EVENT
WHEN TO
SEND
SENDER
ADDRESS
E5
Consumer opts into alerts-based subscription; mandatory

delivery of free subscription opt-in text message receipt.

in > per <event> until you text STOP to <shortcode>.
HELP? <UK standard rate or free helpline number>.
Within 15
minutes
Shortcode
E6
Consumer opts into alerts-based subscription with initial free

period; mandatory delivery of free subscription opt-in text
message receipt.

in > per <event> from <date> unless you text STOP to
<shortcode>. HELP? <UK standard rate or free helpline
number>.
Within 15
minutes
Shortcode
E7
Consumer opts into application-based subscription;

receipt.

in > per <event> until you send STOP to <shortcode>.
HELP? <UK standard rate or free helpline number>.
Within 15
minutes
Shortcode
E8
Consumer completes mobile purchase process; mandatory

delivery of free text message receipt.
FreeMsg: Thank you for your payment of <price in > for

<product or service name> from <Merchant>. HELP? <UK
standard rate or free helpline number>.
Immediately Receipt

Page 121 of 143
Click to go
back to
Contents
Page
REF
EVENT
Consumer completes Web purchase process; mandatory


standard rate or free helpline number>
Consumer completes Payforit Single Click purchase process;

mandatory delivery of free text message receipt.
FreeMsg: Thanks. You have paid <price in > for <product

or service name> from <Merchant>. HELP? <UK standard
rate or free helpline number> Text EXIT to <shortcode> to
stop Single Click.
Consumer completes multiple Payforit Single Click purchases;

mandatory delivery of free summary text message receipt.
Consumer completes Enhanced Purchase Flow purchase

process; mandatory delivery of free text message receipt.
E9
WHEN TO
SEND
SENDER
ADDRESS
Immediately Receipt
E10
Within 15
minutes
Receipt
FreeMsg: Thanks. You have paid <total price in > for

<product service name> from <Merchant>. HELP? <UK
standard rate or free helpline number> Text EXIT to
<shortcode> to stop Single Click.
Within 15
minutes
Receipt
FreeMsg: You have paid <price in > for <product or service

name> from <Merchant> (visited at <time>) HELP? <UK
standard rate or free helpline number> or <unique email
address keyed to MSISDN> or view again at [url]
Within 15
minutes
Receipt
E11
E12

Page 122 of 143
Click to go
back to
Contents
Page
REF
EVENT
WHEN TO
SEND
SENDER
ADDRESS
Consumer completes multiple Enhanced Purchase Flow

purchases; mandatory delivery of free summary text message
receipt.
FreeMsg: You have paid <total price in > for <product or

service name> from <Merchant> (visited at <time>). HELP?
<UK standard rate or free helpline number> or <unique
email address keyed to MSISDN> or view again at [url]
Within 15
minutes
Receipt
E14
Consumer abandons checkout voluntarily or through loss of

service; optional delivery of free service delivery text
message.
FreeMsg: <Merchant> seems to have lost you. To access

their site again please click <Merchant URL>.
Within 15
minutes
Receipt
E15
Consumer opts into marketing; optional delivery of free

marketing text message.
Marketing messages must include

1) FreeMsg.(first)
2) Merchant name.
3) Opt- out information.
May include Merchant URL.
As required
E16
Consumer opts into marketing; optional delivery of free

alternate marketing text message.
Marketing messages must include

1) FreeMsg.(first)
2) Merchant name.
3) Opt- out information.
4) API payment page URL.
As required
E13
Receipt

Page 123 of 143
Click to go
back to
Contents
Page
REF
EVENT
WHEN TO
SEND
SENDER
ADDRESS
E17
Consumer requests code within mobile MT payment flow;

delivery of MSISDN verification code text message.
FreeMsg: Use code <code> to verify your purchase of

<price in > or click this link to complete your transaction <
link to success screen/page/iFrame>.
Immediately Receipt
E18
Consumer requests code within Web MT payment flow;

delivery of MSISDN verification code text message.
FreeMsg: Use code <code> to verify your purchase of

<price in >.
Immediately Receipt
E19
Consumer texts code in MO payment flow; delivery of

purchase verification text message with product / service.
FreeMsg: Your payment of <price in > for <product /

service> from <Merchant> was successful. Click here for
your [product / service /content] <Merchant URL to
product / service> HELP? <UK standard rate or free helpline
number>.
Immediately Receipt
E20
Consumer purchases one-off product via MT-MO hybrid

payment flow; delivery of opt in text message.
FreeMsg: To confirm you wish to proceed with your

purchase of <price in > from <Merchant> reply Y to this
message. Help? <UK standard rate or free helpline
number>.
Immediately Shortcode
E21
Consumer subscribes via MT-MO hybrid payment flow;

delivery of opt-in text message.
FreeMsg: To confirm you wish to proceed with your

subscription of <price in > per <billing frequency> from
<Merchant> reply Y to this message. Help? <UK standard
rate or free helpline number>.
Immediately Shortcode

Page 124 of 143
Click to go
back to
Contents
Page
REF
EVENT
WHEN TO
SEND
SENDER
ADDRESS
E22
Consumer completes mobile gambling purchase process;

mandatory delivery of free text message receipt.
FreeMsg: Thank you for your deposit of xx for <Service

name> from <Merchant name>. Your gambling account has
been credited. Help? <UK standard rate or free helpline
number>.or visit (URL)
Immediately Receipt
E23
Consumer completes purchase process via a tablet that

cannot support shortcode SMS; mandatory delivery of receipt
via email.

standard rate or free helpline number>.
Immediately Ensure
email
address is
not
blocked
E24
Consumer completes mobile purchase process; mandatory

FreeMsg: Thank you for your donation of <price in > for

<charity name>. HELP? <UK standard rate or free helpline
number>.
Immediately Receipt
E25
Consumer completes Double Opt-in Payment purchase

process; mandatory delivery of free text message receipt.
FreeMsg: You have paid <price in > for <product or service

name> from <Merchant> (visited at <time>) HELP? <UK
standard rate or free helpline number> or <unique email
address keyed to MSISDN>
Immediately Receipt

Page 125 of 143
Click to go
back to
Contents
Page
REF
EVENT
WHEN TO
SEND
SENDER
ADDRESS
E26
Consumer opts into recurring payment; mandatory delivery of

free text message receipt.
FreeMsg: You have joined <service name> for <price in >

per <week | month> from <Merchant name> until you text
STOP to <shortcode> to opt out. HELP? <Helpline number>
Immediately Receipt
E27
Consumer opts into recurring payment; mandatory delivery of

spend reminder.
FreeMsg: Reminder. You joined <service name> for <price

in > per <week | month> from <Merchant> until you text
STOP to <shortcode>. HELP? <UK standard rate or free
helpline number>
20 spend
or monthly
at welcome
message
anniversary
Receipt
E28
Consumer opts into recurring payments with initial free

period; mandatory delivery of opt-out and receipt
information.
FreeMsg: You have joined <service name> for <price in >

per <week | month> from <Merchant name> until you text
STOP to <shortcode> to opt out. HELP? <Helpline number>
Within 15
minutes
Receipt

Page 126 of 143
Click to go
back to
Contents
Page
SECTION F - AUDIT LOG REQUIREMENTS

APIs are expected to maintain thorough documentation for each consumer transaction. Listed below are the components necessary for audit logs. At all times,
APIs must be prepared to provide audit logs to MNO, Payforit Management Group, or Customer Service representatives.
APIs must record all purchase process events from the preceding 24 months in an audit log, including the following:
Event timestamp
Consumer (MSISDN, IP address, user agent profile), Merchant, and MNO involved in the event
Event description in clear English
Screen, page, or iFrame grabs from typical events stored frequently
Delivery status of all text message receipts
Description of billing option and payment flow used (e.g., Web MT, Mobile MO)
URL and price of purchased product or service
Event status - success or failure
Abandonment and cancel rates
Please note that individual MNO contracts may extend the 24 month time period. APIs must have clear data protection policies in line with regulations.
If applicable, include the following additional components in the audit log:
Consumers acceptance of the one-off charge, or subscription, and the text presented
Consumers requests to the MNO for a charge or refund and corresponding success or failure
Consumers STOP commands
Consumers subscription termination
APIs unique Payment Code, or subscription code, generation and storage against the associated MSISDN and MT or MO text message
Consumers opt-in to future marketing from the Merchant
If applicable, include the following Payforit Single Click components in the audit log:
MNO approval for the API to operate Payforit Single Click

MNOs approval of the Merchants offered mobile service under Payforit Single Click
Consumers Payforit Single Click opt-in and Payforit Single Click opt-in renewal after 30 or 90 days, whichever happens first

Page 127 of 143
Click to go
back to
Contents
Page
SECTION G CUSTOMER SERVICE REQUIREMENTS

For Customer Service, APIs must adhere to the following provisions. Failure to offer adequate Customer Service results in an immediate service suspension with
reinstatement at the discretion of each MNO based on their individual contractual terms.
1. Merchants must offer a refund or credit facility in line with their legal obligations (including distance selling regulations) and consumers must receive refunds
without unnecessary hurdles.
2. Provide consumer telephone support internally or through contractually obligated Merchants, third party providers (i.e., independent Customer Service
representative), or both.
3. Provide telephone support, at a minimum, Monday through Friday, 9:00 A.M. to 5:00 P.M., and take voicemail messages outside these hours.
4. Respond to consumer support requests within one business day, and resolve consumer support requests within two business days.
5. Advise consumers to text a STOP command to terminate a mobile subscription service or, if requested, terminate a subscription service manually on behalf of
a consumer.
6. All helpline numbers must be a UK non-premium rate number. From 13th June 2014 PPP 12th Code was updated to align with EU Consumer Rights Directive
and consumer complaint facilities can no longer be provided on the 087 or other premium rate number ranges such as 084. Merchants and/or APIs are
required to provide, and effectively publicise, a complaint facility operated on a number range which is compliant with the regulations.
7. All Customer Service must be provided in fluent English language.
8. Merchants and / or APIs must supply an email address for Customer Support as per Cross Network Customer Care Form.

Page 128 of 143
Click to go
back to
Contents
Page
SECTION H PAYFORIT MANAGEMENT GROUP

Payforit Variation for Merchants
A process to allow Merchants that are unable to operate under the current Payforit Scheme rules to still operate under the Payforit Framework,
use the Payforit branding and to operate under the principles and security of the Payforit Payment Environment.
Background
The Payforit Scheme Rules, as amended from time to time are available at Payforit.org. The Scheme Rules are updated and administered by the Payforit
Management Group (PFI MG), made up from representatives from each MNO.
The Payforit Framework is designed for, and works extremely well for, Merchants whose services are being offered to UK based consumers and where the
encounter between the consumer and Merchant is likely to be one-off and/or casual.
In limited circumstances, i.e. where the Merchant is a global player, has an on-going account based relationship with the consumer, already has alternative
payment mechanisms or cannot technically transfer the user to a payment intermediary (charging from inside an application for instance), the current Payforit
Scheme Rules are entirely unattractive and are likely to be unworkable or difficult to apply
However, there are a number of circumstances where the Payforit Scheme Rules could be varied and/or added to so that additional payment flows could operate
within their scope. The MNOs have therefore developed an additional aspect to the Payforit Framework known as the Payforit Variation process, which allows
APIs (on behalf of Merchants) to request that the current Scheme Rules be expanded or adapted to accommodate alternative payment flows. Where appropriate,
any modifications granted will in due course be captured in the Scheme Rules and so be available to all Merchants. However, until that time the modified Scheme
Rules can continue to operate under the Payforit Framework.
Defined Terms
API
Payforit accredited payment intermediary who has a contractual relationship with the mobile operator and aggregates the
capabilities to enable Merchants to deliver a consistent service to all consumers using Payforit screen flows (L1 in PPP definition)
Merchant
Promoter of the service to the consumer (L2 in PPP definition)
PFI MG
Payforit Management Group, currently comprising of a representative from each of Everything Everywhere, O2, Three and
Vodafone in the UK and appropriate secretariat support staff.

Page 129 of 143
Payforit Variation
Approval document from the PFI MG for change to the Scheme Rules under the Payforit Framework
Payforit Framework
Overarching framework under which the current version of the Payforit Scheme Rules sit together with any additional payment
flows that have requested variations to the Scheme Rules but are subject to trial and which comply with the Payforit Principles.
Payforit Principles
Objective set of requirements underpinning Payforit Framework. Also defining the assessment criteria for applications to vary the
Payforit Scheme Rules.
Payforit Scheme
Current publication of the Payforit Scheme Rules on the Payforit website.
PPP
Phone Pay Plus agent of the regulator OFCOM
Payforit Scheme Rules
The rules underpinning the Payforit Scheme
PAYFORIT VARIATION
The API makes an application for variation on behalf of the Merchant.
Payforit Variation will only be granted to services that, for compelling technical, operational or commercial reasons, would be unworkable/very difficult to operate
under the current Payforit Scheme Rules and where the Merchant is able to demonstrate to the PFI MG, that the full principles of the Payforit Scheme would be
satisfied through other mechanisms. (See Payforit delivers these principles:
Any agreed variations to the Scheme Rules will operate within the Payforit Framework and will be available to all Merchants subject to the completion of a
successful trial of the proposed amendment.
The PFI MG will have already explored improvement/changes to the proposed payment mechanism to enable the services to operate within the current Payforit
Scheme Rules (thereby negating the need for Payforit Variation) and it is only in the event that there are compelling technical, operational or commercial reasons
as to why it would be unworkable/ very difficult to make these improvements or changes that an application for Payforit Variation will be considered by the PFI
MG.
Payforit varied services will be able to operate subject to independent commercial agreements across all participating mobile operators.
This section details how the Payforit Variation will operate.

Page 130 of 143
HOW TO APPLY FOR PAYFORIT VARIATION AT A PFI MG MEETING

The PFI MG meets once a month, usually on the afternoon of the third Wednesday of each month. For meeting dates and times please check with the PFI MG
Secretariat (secretariat@payforituk.co.uk).
The PFI MG will review any applications for a Payforit Variation at this monthly meeting. The PFI MG will allocate time to meet with the Merchants and their APIs
who are making the application. There are usually four slots of 30 minutes each available, which are made available on a first come, first served basis.
APIs wishing to attend a meeting should contact the PFI MG secretariat in advance to secure a time. Simple queries can be dealt with by email and the PFI MG will
make additional time available for APIs to present a new flow or amendment where the need arises.
PROVIDING SUPPORTING WRITTEN PROPOSALS

APIs are asked to send supporting written proposals to the PFI MG at least 2 days in advance of the management meeting containing the following information:
A summary document (I page), including:

presentation date;
title of change required;
executive summary of the description of change required;
name of the API (sub L1);
name of the Merchant (L2); and
The change required to the Payforit flows which flows does this impact, what is the specific change required and why?
A short slide deck, including:

all information from summary document;
the proposed consumer experience end-to-end, including mocked up screen shots/text messages from promotion, purchase experience and service
delivery; and
Aspirational launch date (if there is one), including reasons.
The PFI MG Trials process has been simplified for speed. It relies on the submission of full documentation prior to an application which enables the PFI MG to
confirm quickly that the proposal is compliant with Phonepay Plus Code 12 and the Payforit terms as well as ensuring that the due diligence and risk control
processes are robust. The Payforit Management Group Secretariat will work with APIs to ensure that the documentation is complete and processed in a timely
manner by the Payforit Management Group. PFI MG Secretariat will work with APIs to ensure the proper trials process is followed. Documentation for this can
be obtained from the Secretariat (secretariat@payforituk.co.uk)

Page 131 of 143
Click to go
back to
Contents
Page
ASSESSMENT CRITERIA
When assessing an APIs application (on behalf of the Merchant) to use a payment process that varies from the current Payforit Scheme Rules, it is essential to
establish that the variant adheres to the principles of the Payforit Framework.
The Payforit Framework Principles provide for consumers:
Full pricing transparency in a clear way prior to any financial commitment;

Full detail of any service terms that are likely to influence purchasing decision;
Full auditable opt-in by the consumer to the charges;
Inability for any party other than the API to apply charges;
Protection of consumers contact details;
Auditable and informed opt-in to future marketing by the Merchant;
Easy to access and read, detailed terms and conditions;
Electronic receipts, subscription notifications and spend reminders;
Cessation of subscription services through an easy to use method;
Full consumer support for post-transaction enquiries; and
Full audit trails for a minimum period of six months.
The assessment criteria that will be applied by the PFI MG to the application for Payforit Variation is detailed below. The list is non-exhaustive and some items may
not be applicable to the service:
1. The Merchant, company or individual is currently registered and has never been barred from operating PRS in the UK as a consequence of an adjudication
made by PPP;
2. The consumer has an account relationship with the Merchant and has agreed to its terms and conditions;
3. The account of the consumer is password protected;
4. The consumer is provided with clear and relevant information including clear pricing and contact information before purchase is confirmed;
5. The payment flow is user friendly and the consumer journey from product selection to purchase commitment is easy, clear and logical;
6. The consumer will only commit to charging, by selecting a button and there is a mechanism to cancel the purchase prior to commitment;
7. Text receipts are sent (free of charge) to the consumer, and include the merchants name, price paid and support/help contact details;
8. Where the transaction involves repeat charging, reminder mechanisms are in place and provide for a clear cessation method;
9. Protections are in place to prevent unauthorised use and repeat purchases;
10. The maximum amount chargeable in any one transaction, any day and any month is in line with PPP requirements;

Page 132 of 143
11. If the MSISDN (mobile phone number) or any other data of the consumer is captured it is required, stored, and subject to secure IT principles and data
protection laws;
12. It is the responsibility of the API to ensure that an audit trail of consumers consent to purchase is maintained for a minimum period of 24 months and it shall
be available at any time to the relevant MNO on request;
13. Only the API will apply the charges to the consumer bill;
14. Bill description information to be displayed on the consumers mobile phone bill and must be in-line with mobile operator policies;
15. Customer Service contact information is provided prior to purchase and post purchase and is managed by the party requesting exemption and operates 9a.m.5p.m. GMT / BST with calls outside these times recorded and responded to within 24 hours; and
16. A refund process is available for the consumer if they change their mind or are unhappy with or have a faulty product.
Please note that individual MNO contracts may extend the 24 month time period. APIs must have clear data protection policies in line with regulations.
APPROVAL OF PAYFORIT VARIATIONS

The Payforit Framework requires unanimous approval of new Payforit Scheme Rules or variations to the existing Scheme Rules from all network operators before
services can go live.
Once amendments or variations to the current Scheme Rules have been agreed by the MNOs, the Payforit varied services will sit within the Payforit Framework
and the API/Merchant may launch services on one or all of the MNOs networks subject to individual agreements with the MNOs.
Occasionally when new payment flows are proposed to sit within the Payforit Framework, the PFI MG may request that services are trialled against a set of
objective criteria prior to inclusion within the Payforit Scheme Rules for general use by all Merchants/APIs.
The MNO may request reasonable changes/improvements to the payment mechanism (using the criteria in this document) for the service prior to it going live on
their network and the PFI MG is not bound to accept the service as trialled as fit for purpose and reserves the right to conduct further review.

Page 133 of 143
Click to go
back to
Contents
Page
PFI MG APPROVAL PROCESS FOR PAYFORIT VARIATION

All four current network operator members of the PFI MG will have a representative at each management meeting and the secretariat will minute these meetings.
Where possible, and approval is unanimous, the variation will be determined during the meeting.
If the decision is not unanimous, the proposals will be re-worked until a unanimous agreement can be reached. In the unlikely event that a representative from
one of the networks cannot attend the meeting, the decision will be deferred until their attendance is possible and a unanimous agreement can be reached. In
some circumstances, more information or changes may be needed to gain Payforit variation. Where appropriate, the PFI MG will decide and inform the applicant
during the meeting if the continuation of the application can be conducted over email or would require a review at the next meeting. Where possible, the PFI MG
will commit to responding within 10 days of the monthly meeting.
The PFI MG will give one of the following four responses:
1. Sign off: each PFI MG network operator member agrees to use the new flow. If the flow is agreed, the PFI MG signs off by issuing the API with a one page
document detailing the change being accepted (based on submitted proposal) and the dates accepted. The agreed change will be published on Payforit.org
and included in the Scheme Rules so that auditing teams can have a benchmark against which to judge implementation. Once the PFI MG has provided its
approval, each MNO can then independently agree with the API the date on which the flow is ratified to go live on their network. The API will need to follow
each networks standard service go live process.
2. Conditional sign off: approved for use in trial by all PFI MG network members and API needs to deliver supporting customer impact data during the trial. PFI
MG agrees to publish amongst MNOs so auditing teams can have a benchmark against which to judge implementation. Once the PFI MG has provided its
approval, each MNO can then agree independently with the API the date the flow is ratified to trial on their network and APIs should follow each networks
standard service trial go live process.
3. Rejection: a one page response will be issued by the PFI MG outlining the reasons for the rejection and inviting the API to re-submit the application if there are
material changes to the circumstances/position. If at all possible, the PFI MG prefers not to reject proposals but to work with APIs to improve proposals so that
they can meet the necessary requirements to operate within the scope of the Payforit Framework. Consultation with PPP is part of PFI MGs approval process
for new flows, with PPP usually being consulted once a proposal has nearly reached the final draft stage. In some cases it may be appropriate to invite a PPP
representative to observe an API proposal at a PFI MG meeting.
4. Next steps: if further work is required a one page response will be issued by the PFI MG stating amendments required. This will require another detailed
presentation to be made.

Page 134 of 143
In the event that the application to the PFI MG for Payforit Variation has been rejected or the API is dissatisfied with the Next Steps required to enable the service
to operate within the Payforit Framework, the API can escalate their application to the line managers of the PFI MG representatives, details of which will be
provided on application.
In the event that the application to the PFI MG for Payforit Variation has been rejected or negotiations have failed so that the service is unable to operate within
the Payforit Framework, the Merchant / API can seek individual MNO approval to operate the service on the relevant MNO (without using the Payforit brand and
operating outside the Payforit Framework). Alternatively, each network operator can approve or refuse the service based on its individual criteria at its own risk
and in doing so is operating as a single commercial entity, independent of the PFI MG and outside of the Payforit Framework.
NETWORK OPERATOR IMPLEMENTATION OF THE PAYFORIT VARIATION

Once the PFI MG has in principle approved an application for Payforit Variation, each network is free to independently implement that Variation in accordance
with a bilaterally agreed roadmap with the API.
OBLIGATIONS ON APIS FOLLOWING PAYFORIT VARIATION

Once the PFI MG is satisfied that the proposed service has met the assessment criteria and a Payforit Variation has been issued to the API, the API must operate
the service as varied and must not make any modifications to the service that would materially affect the mobile charging aspect of the service without approval
from the PFI MG.
The Payforit approval will contain a detailed description of the service and the payment mechanisms plus other assessment criteria detailed in the application.
Visual representations of user flows and screen flows will be contained in the documentation. The Payforit document will also contain a record of the requests
that the PFI MG made to the API/Merchant and the subsequent commitments made.
MONITORING
APIs will provide due diligence and risk control assessment to the adherence of varied services agreed at the time of the Payforit Variation. Monitoring will be
carried out independently with a view to identifying issues that would give potential rise to consumer harm. Subject to compliance with competition law, MNOs
may share relevant intelligence with each other about any issues identified [E.g. where a provider is not providing text receipts/operational customer service lines]
for the limited purpose of preventing consumer harm and fraudulent activities. The PFI MG will agree the next steps to be taken collectively and each MNO will
assess its own independent position under its commercial agreements. The Red and Yellow card process available from www.short-codes.com will be applied.

Page 135 of 143
Click to go
back to
Contents
Page
WITHDRAWAL OF PAYFORIT VARIATION

A sign off or conditional sign off is subject to the condition that if unintended consequences arise that attract an unacceptable level of complaints about consumer
harm or fraudulent activities then any network operator can suspend a flow immediately. In such cases, the PFI MG would work with the API to try to rectify the
situation. If no resolution can be found with the PFI MG, the API must be given 30 days notice prior to the removal of their flow from the Payforit Scheme Rules.
OTHER WAYS TO COMMUNICATE WITH THE PFI MG

If APIs have general questions for the PFI MG, they should contact the Secretariat in the first instance before booking a slot at a meeting, as the question may be
easily resolvable by phone or email.
Please check the API log-in area for the latest scheme rules, flow approvals and other news.
The PFI MG Secretariat will have a slot in the monthly AIME newsletter to provide PFI updates.

Page 136 of 143
Click to go
back to
Contents
Page
SECTION I - PAYMENT LIBRARIES REVIEW AND ACCEPTANCE CRITERIA

Payment Libraries are handset client libraries which manage the payment screens and billing screens presented to the end user in Merchant applications.These
libraries are used by Merchants when creating applications, and are compiled into the application. These libraries can be used across a wide range of applications
from different Merchants. These libraries cannot be altered or changed by the Merchant in any way, and so support the Payforit principles where the Merchant
has no influence over the presentation of payment information to the end user, or the acceptance of the charge by the end user.
Payment libraries can either be provided by APIs, or can be provided by independent companies (Payment Library Provider) who are not accredited APIs for
Payforit and so do not have a direct commercial
agreement with the MNOs. Payment Library
Providers are generally not also the App
provider (Merchant). Because of this, the PFI
MG has proposed that the APIs should be free
Operator
to contract directly with Payment Library
companies in an arrangement where
Review and
Subscriber
acceptance of
Payforit Scheme
contract for
The Payment Library company will
payment library
Rules
mobile service
provide the library which manages the
Compliance
provision
In-app Billing Presentation, Flow and
Payment
Charging
End User acceptance of the charge
Library
The API will manage the charging, SMS

receipting, contract management and
liaison with the PFI MG
API
RELATIONSHIP BETWEEN PARTIES
The relationship between the different parties

involved in the In-App Payment Flow is shown
in this diagram. Under strictly controlled
circumstances the payment library may be
provided by the Merchant itself. These
circumstances are detailed below.
Contract for
services
Billing to
subscriber
Receipt messages
Billing instruction
to API
Provision and
display of content
App
Service promotion
and advertising
Terms and
conditions
Contractual
relationship between
API and App
Development/
Billing of advertised price
Consumer

Page 137 of 143
Click to go
back to
Contents
Page
PAYMENT LIBRARY REQUIREMENTS

The Payment Library and the Payment Library Provider shall meet the following requirements to ensure that it provides a secure purchase experience with an
appropriate level of control by the payment library provider and API;
The Payment Library Provider shall physically secure their offices and any hosted infrastructure to prevent unauthorised access or changes to the library,
systems and data. This shall be subject to audit.
The Hosted Infrastructure facilities should demonstrate that they meet the following standards;
ISO 9001:2008 Quality Management Standard

ISO/IEC 27001:2005 Information Security Management
ISO/IEC 27001:2005 Information Security Management
PCI DSS (Payment Card Industry Data Security Standard) Attestation PCI DSS
The Payment Library Provider shall demonstrate the measures in place to secure the integrity of the Payment Library including;
Prevention of reverse engineering of the library by third parties using second generation obfuscation software
Encryption of traffic to prevent interception of the Data
Authentication of traffic to protect the integrity of the Data
Examples of measures that should be taken are shown in the following paragraphs.
PREVENTION OF REVERSE ENGINEERING

The payment library code shall be adequately obfuscated with particular attention paid to String obfuscation on security keys such as hashing salts.
Second generation obfuscation software shall perform the following:
Name and string encryption

Application size reduction
Watermark functionality

Page 138 of 143
Flow obfuscation.
The payment library's internal processes shall not be exposed to or changeable by the client app.
The payment library provider shall identify particular versions of the payment library and be able to ensure that purchases can be restricted by version.
For the purposes of maintaining library integrity and verification of the sender, any distribution of the payment library shall always be encrypted utilising either
PGP or GPG.
ENCRYPTION OF TRAFFIC TO PREVENT INTERCEPTION OF THE DATA

SSL shall be mandated for communication between the payment library and the backend system, apart from HTTP connections to the API used for MSISDN passthrough.
The SSL certificate shall be a High Grade encryption using AES-256 (256 bit keys). Please note that 128 and 192 bit SSL will not meet the Payforit Management
Group requirements.
AUTHENTICATION OF TRAFFIC TO PROTECT INTEGRITY OF THE DATA

The client app and the payment library shall to be positively identified by the payment library provider's backend system.
The Merchant shall be identified through a unique Service ID, which is passed between the app and the payment library at transaction initiation. This ID must also
exist on the payment library provider's server to ensure that only approved pricing and payment flows associated with that particular Merchant is presented inapp.
The payment library shall identify and reject any library payment requests which contain an unapproved service ID.
The payment library shall control the presentation of the payment information to the consumer in accordance with Payforit guidelines. This information shall
always be the current information (i.e. the library must accommodate any updates /changes to rules or payment flows after app download).
The payment library shall use a cryptographic hashing algorithm in all communications where data is passed in parameters to maintain integrity of the message.
The following hash function may be used to generate a message digest:
SHA-2 224/256/384/512 bit message digest
Additionally the payment library provider shall maintain a complete audit trail of the payment library's activities and session data on its backend system.
The Payment Library Provider shall provide evidence of the measures they have put in place to meet the above requirements, This shall include not just evidence
of the design principles in place, but additional independent evidence such as standards certification or penetration testing by 3rd parties.

Page 139 of 143
Click to go
back to
Contents
Page
SERVICE REVIEW AND ACCEPTANCE

This process will be used for every service and Merchant that uses In-App billing as described below.
This process would require that;
Payment Libraries need to be reviewed and accepted by the PFI MG.

Merchants connected using an accepted Payment Library can be approved by the API, however, full Merchant and Service vetting needs to be completed
by the API.
ACCEPTANCE OF PAYMENT LIBRARIES

The PFI MG will review the proposed library payment flow and operation with both the API and the Payment Library company and will either accept or provide the
suggested changes and improvements to accept the library based on the fit with the Payforit principles and required payment flow.
Payment Library provider is required to ensure the purchasing experience is in line with the Payforit Embed Flows (see Embed Method for HTML5 Devices).
This acceptance will also include a security audit of the Payment Library Provider as well as the Payment Library operation.
The Payment Library Provider is then responsible for notifying the API and PFI MG of any changes to the library that would change the proposed payment flow and
operation.
Once accepted with one API, an independent payment library is then accepted for use with other APIs, as long as the payment library user experience and
functionality are unchanged,
If the payment library is changed significantly between versions, then a new review will be required.
These changes would include;


Page 140 of 143
Click to go
back to
Contents
Page
ACCEPTANCE OF MERCHANTS USING AN INDEPENDENT PAYMENT LIBRARY

Once a payment library is accepted, then it can used to provide In-App charging across multiple Merchants and APIs, without further acceptance by the PFI MG.
The API will be required to approve the Merchant and service before they can be launched, including but not limited to, Merchant checks against the PPP Register
and Companies House.

Page 141 of 143
Click to go
back to
Contents
Page
ACCEPTANCE OF MERCHANTS USING OWN PAYMENT LIBRARY

Merchants can also be approved - in exceptional cases - to provide In-App charging without using an accepted payment library. These Merchants are expected to
be FSA regulated and have an account relationship with users of their App.
The API should use the template in Section H Payforit Management Group to bring forward a request for variation
Once acceptance has been given, the responsibility will rest with the API to ensure that the Merchant service matches the accepted flow and that the Merchant
does not deviate from it. This will include ensuring an audit trail is made available, including the capture of screenshots of the live application on a regular interval,
random testing and any other means that seem appropriate to ensure correct pricing and consumer protection.
The diagram below demonstrates the value chain of Merchants using their own Payment Libraries

Page 142 of 143
Click to go
back to
Contents
Page
ACCEPTANCE OF AN API USING OWN PAYMENT LIBRARY

The PFI MG will review the proposed library payment flow and operation with the API and will either accept, or provide suggested changes and improvements in
order to accept the library based on the fit with the Payforit principles and required payment flow.
This acceptance will also include a security audit of the API and the Payment Library operation.
The API is then responsible for notifying the PFI MG of any changes to the library that would change the proposed payment flow and operation. If the payment
library is changed significantly between versions, then a new review may be required.
These changes would include:

The API will need to present on behalf of the Merchant to the PFI MG:
Justification why the Merchant should not use a payment library

Evidence that the Merchant Payment Flow matches the required payment flow, including a documented flow and screenshots.
What additional measures are in place to mitigate any risk to the end user.
Once acceptance has been received, the responsibility will rest with the API to ensure that the Merchant service matches the accepted flow and that the Merchant
does not deviate from it. This will include ensuring an audit trail is made available, including the capture of screenshots of the live application on a regular interval,
random testing and any other means that seem appropriate to ensure correct pricing and consumer protection.
Payment Library provider is required to ensure the purchasing experience is in line with the Payforit Embed Flows (see Embed Method for HTML5 Devices).

Page 143 of 143
END OF DOCUMENT

Payforit Scheme Rules 4 1 4 Published 21november14

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Payforit Scheme Rules 4 1 4 Published 21november14

Uploaded by

Copyright:

Available Formats

PAYFORIT SCHEME RULES 4.1.

PAYFORIT SCHEME RULES VERSION 4.1.4

PAYFORIT SCHEME RULES 4.1.4

PAYFORIT SCHEME RULES 4.1.4

PAYFORIT SCHEME RULES 4.1.4

PAYFORIT SCHEME RULES 4.1.4

PAYFORIT SCHEME RULES 4.1.4

PAYFORIT SCHEME RULES 4.1.4

Payforit Session .......................................................................................................................................................................................................................... 97

Subscription and Service Transactions ....................................................................................................................................................................................... 97

All MT and Hybrid based Consumer Experience Flows ............................................................................................................................................................... 98

MT- MO Hybrid Consumer Experience Flows ............................................................................................................................................................................. 98

MO Consumer Experience Flows ................................................................................................................................................................................................ 99

Payforit Single Click .................................................................................................................................................................................................................... 99

Enhanced Purchase flow........................................................................................................................................................................................................... 101

Gambling Purchase Flow .......................................................................................................................................................................................................... 103

Double opt-in flow .................................................................................................................................................................................................................... 104

Error Descriptions ................................................................................................................................................................................................................. 106

Text Receipts ........................................................................................................................................................................................................................ 106

MSISDN ................................................................................................................................................................................................................................. 107

Alternate Mobile Processing ............................................................................................................................................................................................. 107

Screen Display Processing..................................................................................................................................................................................................... 108

Payment Failure .................................................................................................................................................................................................................... 109

Section D - Style Rules .......................................................................................................................................................................................................................... 110

Pricing Notification Field........................................................................................................................................................................................................... 110

Merchant Name ....................................................................................................................................................................................................................... 111

PAYFORIT SCHEME RULES 4.1.4

Price .......................................................................................................................................................................................................................................... 111

Payment Received Notification ................................................................................................................................................................................................ 111

Screens, Pages, iFrames, and Buttons ...................................................................................................................................................................................... 111

Embed Method for HTML5 Payments ...................................................................................................................................................................................... 112

Enhanced Purchase Flow .......................................................................................................................................................................................................... 112

Double Opt-In Flow .................................................................................................................................................................................................................. 114

Payforit Logo ............................................................................................................................................................................................................................ 115

MNO and API Logo Placement .............................................................................................................................................................................................. 116

Merchant Logos, Slogans, and Designs ................................................................................................................................................................................. 117

Payforit Single Click Logo and Button ................................................................................................................................................................................... 117

Section E - Text Message Mandated Language .................................................................................................................................................................................... 118

PAYFORIT SCHEME RULES 4.1.4

PAYFORIT SCHEME RULES 4.1.4

PAYFORIT SCHEME RULES 4.1.4

Full pricing transparency in a clear way prior to any financial commitment

For Merchants, Payforit delivers:

PAYFORIT SCHEME RULES 4.1.4

PAYFORIT SCHEME RULES 4.1.4

PAYFORIT - A WORKED EXAMPLE

PAYFORIT SCHEME RULES 4.1.4

CONSUMER EXPERIENCE SCENARIOS

Sample Payforit Consumer Experience Flows

One-off payments; (Buy now)

HTML5 supporting devices

See Payforit Consumer Experience Flows for full information.

Single Click Button

PAYFORIT SCHEME RULES 4.1.4

ROLES AND RESPONSIBILITIES

PAYFORIT SCHEME RULES 4.1.4

Due Diligence and Risk Control (DDRC)

PAYFORIT SCHEME RULES 4.1.4

PAYFORIT SCHEME RULES 4.1.4

PAYMENT LIBRARY RESPONSIBILITIES

PAYFORIT SCHEME RULES 4.1.4

Users returning from Payment pages

PAYFORIT SCHEME RULES 4.1.4