PAYFORIT SCHEME RULES TRANSA PAYFORIT SCHEME RULES 5.0

5.0 1 of 43 Version Control: Date Changes 4.1.1 4.1.6 Payforit Scheme Rules CCR 5.0 22 May 15 1 Sept 15 PUBLISHED 1 ST SEPTEMBER 2015 Pre CCR see Full Document filed on the website for legacy 4.1.6 General information shortened and applied to CCR &13 th Code for relevance Branding altered to emphasise charge to mobile element MSISDN Pass-Through flow converted to Double Opt-in MT, MO and Hybrid flows altered to clarify consent to charge Swift Payment Flow removed Double Opt-in Flow expanded to cover 4 variants: Single Purchase, Competitions, Subscriptions, Time Ltd Access Gambling and In App flows temporarily removed to ease implementation (still remain in Full Document at www.payforit.org) Layout amended to ease navigation All screens are for illustrative purposes only please refer to CSS HTML files in the Asset File behind the log in on www.payforit.org. NB Success and Failure screens may have been removed from the illustration to save space. They are still required as per the rules.

CONTENTS 2 of 43 Section A - General rules and Statutory Regulation... 4 Section B - MNO and API Obligations... 5 Merchant Obligations... 6 Sections C & D - Payforit Transaction and Style Rules... 8 1 All Flows... 8 1.1 Transaction Rules... 8 1.1.1 Payforit Session... 8 1.1.2 MSISDN Handling... 9 1.1.4 Subscriptions and recurring payments... 11 1.2 Common Screen Items and Style Rules... 12 1.2.1 Header Box... 13 1.2.2 Merchant Detail... 13 1.2.3 Charge Notification... 13 1.2.4 Screens, s, iframes and Buttons... 14 1.2.5 Payment Received Notification... 16 1.2.6 Error Rules... 16 1.2.7 Payment Failure... 17 1.2.8 Payforit Logo... 17

3 of 43 Click to go 1.2.9 Merchant Logos, Slogans and Designs... 17 2 MT (and Hybrid) Flow Rules... 18 3.1 MT Flow Transaction Rules... 18 3.2 MT Flow Screens... 19 3 MO Flow Rules... 21 4.1 MO Flow Transaction Rules... 21 4.2 MO Flow Screens... 22 4 MT MO Hybrid Flow Rules... 23 5.1 MT MO Hybrid Flow Transaction Rules... 23 5.2 MT MO Hybrid Screens... 24 5 Web Flow Specific Rules... 26 8 Double Opt In Flow Specific Rules... 27 8.1 Double Opt-in Flow Transaction Rules... 27... 30 8.2 Double Opt-in Flow Screen Rules... 34 Section E - Text Message Mandated Language... 37 Section F - Audit Log Requirements... 42 Section G Customer Service Requirements... 43

4 of 43 Click to go SECTION A - GENERAL RULES AND STATUTORY REGULATION Accredited Payment Intermediaries (APIs) operating the Payforit Scheme must follow the Payforit Scheme Rules. The Payforit Scheme applies to all services that are discovered and consumed on the internet and charged to the mobile user s account regardless of the device the consumer is using to access the service and whether or not that device is connected to the internet via a mobile network, Wi-Fi facility, broadband or other means. Payforit provides a consistent series of payment screens that deliver clear pricing information, easy access to terms and conditions and Merchant contact information before and after the sale. A consumer must have full understanding about information that is material to their decision to purchase BEFORE they enter a binding contract and they must explicitly acknowledge their obligation to pay using a Buy Now button. Confirmation of the purchase must be delivered in a durable medium (text message) within a reasonable time. Merchants are responsible for the ability to deliver contracts to customers. (The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR)) 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 ). www.phonepayplus.org.uk/~/media/files/13th-code-of-practice/13th-code-of-practice.pdf Payforit APIs and Merchants are also bound by all applicable UK and EU laws and regulations. The requirement to comply with the Scheme Rules and the circumstances as to when they should be applied is governed independently by each Mobile Network Operator (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. In the event of a breach 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 API s 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 from operating under the Payforit Scheme Apply sanctions where services are fully compliant but complaint levels or customer satisfaction scores are deemed to be unacceptable Payforit delivers these principles: Full pricing transparency in a clear way prior to any financial commitment

5 of 43 Click to go 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 consumer s 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 12 months For Merchants, Payforit delivers: Easy integration to the payment process Compliance with the pricing principals stated in the PPP 13th Code of Practice, The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR) Payforit is not designed to deliver: Full compliance with UK legal and regulatory requirements 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. SECTION B - MNO AND API OBLIGATIONS The Mobile Network Operator (MNO) is responsible for the consumer s mobile account, provides the identity of the consumer s 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. MNOs:

6 of 43 Click to go 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 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 Accredited Payment Intermediaries (APIs) contract with providers of online digital products and services to enable the mobile payment part of the consumer s purchasing journey when they are accessing internet services. The Payforit Scheme places the responsibility on the API to provide the required information to the consumer before they make the decision to purchase. The API facilitates the charges on behalf of the Merchant only after authorisation is gained from the consumer via the Payforit approved Consumer Experience Flows. It is the API s responsibility to carry out due diligence on the Merchant, their services and the clarity of information available to the consumer in line with The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR) and PPP 13th Code of Practice prior to the Payforit screen. When the Payforit information becomes part of the Merchant s environment 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 and to ensure that approved services do not change and take action where they are no longer confident of being able to ensure total compliance with the Scheme Rules. The API will also be held responsible for the manner in which affiliate marketing traffic is delivered. 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 highly successful service could, however, indicate a separate issue that should be investigated. MERCHANT OBLIGATIONS 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 and provides post-sale Customer Service for consumers. Merchants should ensure that consumers receive the relevant digital products or service in line with their legal rights. Merchants need to ensure that they work together with the API to ensure that the Consumer Experience Flow is logical, consistent and compliant with The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR) and PPP 13th Code of Practice The consumer must have all information material to the decision to purchase in an easily accessible, clearly legible and simply understood format BEFORE they enter into a binding contract. The call to action must be clear and correct and stand alone so that the consumer can explicitly acknowledge their obligation to pay. When the Payforit

7 of 43 Click to go information becomes part of the Merchant s 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. Services with complex terms such as competitions, MUST 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. Merchants must deliver to a consumer (by MSISDN) a consistent user experience for a single service across all APIs. Each service must have the API s due diligence and risk control process applied before going live. It is the responsibility of the Merchant to ensure they are consistent and transparent with their pricing so 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, how they can receive the product after purchase and their rights around cancelling the 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. Only the words given in the Scheme Rules are permitted on the Payforit pages. Questions, offers and other text not part of the consent to charge process must not be mixed with the consent to charge on the Payforit payment page. To prevent click training any pages before the PFI payment pages may not use the Payforit header box, nor anything that approximates to it. The header box attributes are its location, size, quantity of lines of text, and their fonts etc - these must not be used in a replica box. The payment button also must not be replicated on preceding pages. The attributes of the button include location, button colour, button size, colour of text, number of lines, length of lines. The button colour and size must never be replicated. The Payforit Scheme Rules are clear that a consumer must not be misled. Rogue affiliate marketing practices including forced redirections and misleading journeys can result in significant brand damage and consequently infringements could have implications for continuing participation in the Scheme. 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. 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. Merchants must also ensure they provide a simple method of permanent exit from the service and that this is clearly informed in line with CCR. Merchants must offer a refund or credit facility in line with their legal obligations and consumers must receive refunds without unnecessary hurdles. (NB Consumers will be entitled to a refund within 14 days of making a purchase unless there is provision for waiving these rights within the contract and they will also be entitled to a refund if these or other rights are not clearly informed and protected. The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR) Customer Service numbers (or email addresses by explicit permission of the MNOs) must be available to the consumer prior to purchase, as per PPP 13th Code of Practice. This includes the requirement that no phone charges are in excess of basic rate for post contract phone queries and that only compliant numbers are used.

8 of 43 Click to go SECTIONS C & D - PAYFORIT CTION AND STYLE RULES This section covers the detailed processing of screens, displays, charging, and background technical processing of each of the Payforit Consumer Experience Flows 1 ALL FLOWS These rules facilitate compliance with Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR) and PPP 13th Code of Practice To enable auditability for independent third parties (API), to provide robust evidence of consent to charge and to protect the consumer from being misled or harmed. Unless specified otherwise in the Consumer Experience Flows all relevant Transaction Rules must be applied. 1.1 Transaction Rules 1.1.1 Payforit Session 1.1.1.1 Create a unique session ID at the entry point to each Payforit request. 1.1.1.2 Retain the same session ID for all navigation within one session. 1.1.1.3 Log the session ID as charged when the consumer is billed. 1.1.1.4 Check the billed status of each session before each billing request to ensure the MSISDN has not been charged previously. 1.1.1.5 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.1.1.6 Charge the MSISDN only once per session. 1.1.1.7 Send text receipt message once charge has been made. See Section E - Text Message Mandated Language 1.1.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 etc from shortcode SMS must go by email. 1.1.1.9 Merchant must supply consumer with their product or service immediately after purchase completion and successful billing. 1.1.1.10 The Help Section in the header 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. 1.1.1.11 The Help links for Merchant and Payforit terms must be separate. 1.1.1.12 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. 1.1.1.13 The Cancel Purchase Link must take the consumer the Merchant Screen with the Merchant advised that the consumer has cancelled so that correct business logic can be deployed.

9 of 43 Click to go 1.1.2 MSISDN Handling 1.1.2.1 Obtain the MSISDN only from the consumer s 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. 1.1.2.2 Only pass the MSISDN to the Merchant under contract solely for the purposes of: Product or service delivery; Customer Service; Marketing (but only if the marketing opt-in tick is ticked by the consumer 1.1.2.3 In all other cases, APIs must safeguard consumer MSISDNs from Merchants and other APIs. 1.1.2.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). 1.1.2.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. 1.1.3 MSISDN Verification Requirements - Ensure that the same level of security protects consumers across all APIs, to ensure robust MSISDN verification takes place before they are charged. 1.1.3.1 MT VERIFICATION METHOD 1.1.3.1.1 Generate a random code of 4 or more alphanumeric characters 1.1.3.1.2 A code used in the previous 5000 transactions may not be selected 1.1.3.1.3 The SMS message must start with FreeMSG and make it clear the user is verifying their purchase intent 1.1.3.1.4 If the MSISDN is invalid three times, then the API should consider moving to an MO Flow if supported or cancel the purchase. 1.1.3.1.5 Send pricing information in all text messages sent to the consumer, except service delivery text messages. 1.1.3.1.6 Send the free to-consumer purchase verification code text message to the MSISDN entered by the consumer. 1.1.3.1.7 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 1.1.3.1.8 Ensure the purchase verification code expires within 15 minutes of being sent. 1.1.3.1.9 Switch the consumer to a MO flow (if supported by API) after three unsuccessful attempts to enter the purchase verification code. 1.1.3.1.10 If MO flow not supported by API, abandon the transaction after three unsuccessful attempts to enter the purchase verification code. 1.1.3.1.11 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). 1.1.3.1.12 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). 1.1.3.1.13 Include, optionally, a URL in the purchase verification code text message for Mobile flows that the consumer may click to complete purchase. 1.1.3.1.14 Limitations for the URL included in the MT message are; 1.1.3.1.14.1 URL may be clicked only within 15 minutes of the message being sent 1.1.3.1.14.2 URL must enforce no more than one charge per click

10 of 43 1.1.3.1.14.3 URL must not identify the consumer MSISDN directly; a MSISDN alias must be used. 1.1.3.1.14.4 URL, once clicked, must take the consumer to the API payment success screen 1.1.3.1.14.5 Charge the MSISDN and deliver product if the correct purchase verification code is entered within 15 minutes 1.1.3.1.15 Charge only the MSISDN from which the purchase verification code originated and terminated 1.1.3.1.16 A dropbox for the consumer to select their own network can be provided. 1.1.3.2 MO AUTHENTICATION METHOD 1.1.3.2.1 Use a unique verification code of at least 4 characters that will link the Payforit session with the MO message. 1.1.3.2.2 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. 1.1.3.2.3 Link the consumer the payment success page for mobile within text message receipts. If the Merchant site cannot support re-entry via a link then the MO method may not be used. 1.1.3.2.4 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 1.1.3.2.5 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. API must host the short code used to send the MO message to (subject to Network requirements). Virtual numbers are not permitted for MO opt in (big numbers 07xxx). 1.1.3.3 HYBRID AUTHENTICATION METHOD 1.1.3.3.1 The SMS message must contain the price information. 1.1.3.3.2 The SMS message must start with FreeMSG and make it clear the user is verifying their purchase intent 1.1.3.3.3 If the MSISDN is incorrectly formatted, the API serves the error text. If the MSISDN is invalid three times, then the API should consider moving to the MO Flow if supported or cancel the purchase. 1.1.3.3.4 If the response text message is not received in 5 minutes, present the relevant Failure Screen 1.1.3.3.5 Use a unique verification code or clicking on a link inside an SMS that will link the Payforit session with the MO message 1.1.3.3.6 Charge the MSISDN only if it responds with the keyword within 15 minutes. 1.1.3.3.7 Expire verification code or link inside an SMS after 15 minutes and reject transactions that are using expired codes or links. 1.1.3.3.8 Ensure the keyword is alphanumeric, with at least one character or clicking on a link inside an SMS 1.1.3.3.9 Ignore additional keywords or links sent by the consumer after the verification keyword or link 1.1.3.3.10 API must host the short code used to send the MO message to (subject to Network requirements). 1.1.3.4 IVR AUTHENTICATION METHOD 1.1.3.4.1 The consumer must be made aware of the call duration and cost prior to calling

11 of 43 1.1.3.4.2 Only standard rate or less IVR numbers may be used 1.1.3.4.3 An IVR line must be randomly selected from a pool of at least 400 numbers 1.1.3.4.4 The IVR numbers and termination point must be controlled by the API 1.1.3.4.5 Calling a number must only verify the MSISDN and a charging process may only be commenced once it is established the consumer has returned to the Payforit session. 1.1.3.4.6 Once an IVR line has been presented it must not be reused for at least 30 minutes 1.1.3.4.7 The consumer must call the IVR line within 15 minutes of it being presented otherwise the authentication should be rejected 1.1.4 Subscriptions and recurring payments 1.1.4.1 Price and duration must be clear and prominent directly before the order in large, legible font. 1.1.4.2 A simple method of termination (STOP unless otherwise agreed with MNO) of the service must be clearly informed before the order is made. 1.1.4.3 API must send a free to-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 1.1.4.4 Merchant must supply consumer with their product or service immediately after purchase completion and successful billing 1.1.4.5 API must send free-to-consumer subscription reminder text (or email) messages every month or every 20 (including VAT), whichever happens first 1.1.4.6 API must support the termination method and the shortcode to which it is sent 1.1.4.7 Depending on the MNO, if API uses another shortcode to effect billing for Subscription, then this must also support the termination method to opt-out of subscription 1.1.4.8 API must charge consumer for Subscriptions triggered by that API only. (This is does not preclude auditable service migration to a new API) 1.1.4.9 API must ensure that billing requests to MNOs are for valid, active subscriptions and services only 1.1.4.10 The subscription service will be automatically cancelled following a 120 day period of inactivity. (Virus checkers and similar are exempted from the Rule) Inactive means the subscriber has not downloaded content, or sent any MO SMS to the service provider. Subscribers who browse a service mobile or web-site will be considered to be active. This rule will not apply to push services, or services which are seasonal or where an annual billing charge is applied. 1.1.4.11 See Consumer Experience Flows for any additional requirements

1.2 Common Screen Items and Style Rules 12 of 43 is Common screen items appear across multiple Consumer Experience Flows. The common API controlled items and consumer input are illustrated below using Mobile Screens. All screens are for illustrative purposes only. 1. 2. Header Box 3. (Mandated): When clicked by the consumer, 4. the API will present the About Payforit 5. screen. 6. Merchant 7. Detail (Mandated): Can carry either the 8. Merchant Brand or the Merchant Name and 9. must be recognisable from the consumer 10. journey to this screen 11. Charge Notification 12. (Mandated): A short, clear, unambiguous 13. explanation of the service being 14. offered for purchase must be displayed 15. on every page of the flow used. This should 16. explicitly state This will be charged to 17. your mobile phone (non-phone devices must reference the device) Call to Action First Purchase button (Mandated): Dependant on the Flow it can read Buy Now, Subscribe Now, Donate Now. Continue and Next are intermediate instructions only. Call to Action Second Purchase button (Mandated): When the MSISDN is confirmed the charging notification along with the price must appear on the second payment button: Click to confirm you accept that <price> will be charged to this mobile. Help (Mandated): Must contain the Merchant or API support details with links to Merchant and Payforit terms and information Error reason (Mandatory): API will present the reason for the error using the Error Reasons permitted Retry button (Mandated): This will return the consumer to the Payment page to retry the transaction or cancel and return to the Merchant. MSISDN Entry box for MT Flow Consumer will enter their number for verification. A dropbox for consumers to select their own network can be provided. Payment Received Notification (Mandated): Advises the consumer the amount that they have paid from their mobile account and must match the price shown on previous screens. Don t know your mobile number? link (Optional): eg when using broadband. This clickable link switches the Consumer Experience Flow from MT to MO flow. Marketing Opt In (Optional): Allows the Merchant to conduct marketing to the consumer. Box must be unticked.

13 of 43 About Payforit (Mandated) Payforit is a technical payment scheme developed by the UK mobile network operators ( networks ), to make buying digital products and services via a mobile phone or other device simple and clear for you and enabling you to charge these purchases to your mobile monthly account or prepaid credit. The scheme is operated by parties (called Accredited Payment Intermediaries) that contract to your network to provide the relevant information to you so that you can make your own decision about the purchase. Payforit is not a legal entity and is not a party to any transaction for products or services. These rules facilitate compliance with Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR) and PPP 13th Code of Practice Consumers must be clearly informed of all information likely to influence the decision to purchase prior to entering a binding contract. Consumers must explicitly acknowledge the obligation to pay. Consumers must not be misled. Unambiguous words must be used. (CCR & 13 th Code). Unless stipulated elsewhere in this document the Style Rules below must be followed. 1.2.1 Header Box 1.2.1.1 The header box is mandated and supplied by the Payforit Management Group and must be static (floating) 1.2.1.2 The header box must only be shown at the top of the Payforit purchase stages and may not be shown on any promotional page in the consumer journey. 1.2.1.3 No other form of header box using a similar style is permitted on the promotional pages. 1.2.1.4 The header box will contain the following items: 1.2.1.4.1 Payforit logo and merchant terms links 1.2.1.4.2 MNO logos as shown 1.2.1.4.3 Exit button 1.2.1.4.4 Help details 1.2.2 Merchant Detail 1.2.2.1 Can carry either the Merchant Brand or the Merchant Name and must be recognisable from the consumer journey to this screen 1.2.2.2 Merchant Detail on unbranded payment flows, must; 1.2.2.2.1 Contain the name of the Merchant, recognisable from the prior part of the consumer s journey; 1.2.2.2.2 Contain the word From when the transaction is a purchase E.g. From Factory Direct ; 1.2.2.2.3 Contain the word To when the transaction is a donation. To Children in Need. 1.2.2.2.4 The name of the Merchant must be the same name used in text receipts. 1.2.2.2.5 1.2.3 Charge Notification

14 of 43 Click to go 1.2.3.1 A description of the product or service must appear immediately above the call to action buttons. A short, clear, unambiguous explanation of the service being offered for purchase must be displayed on every page of the flow used: 1.2.3.1.1 One-off payment: Buy < product / service > 1.2.3.1.2 One-off charity donation: Donate to <charity name> 1.2.3.1.3 Charity subscription: Donate to <charity name> per <Billing Frequency> until you text STOP to <shortcode> 1.2.3.1.4 Standard subscription: Subscribe to < product / service > per <Billing Frequency> until you text STOP to <shortcode> 1.2.3.1.5 Subscription with initial free period: Subscribe to < product / service > free for <Period> and then be charged per <Billing Frequency> 1.2.3.1.6 Subscription with initial charge: Subscribe to < product / service > per <Billing Frequency> after x [Mins Hours Days Weeks Months] until you text STOP to <shortcode> (or acceptable alternative). A charge time/date notice must be in the SMS receipt and sending STOP or other termination method before that time means no charge is made. 1.2.3.2 The Charge Notification must also explicitly state This will be charged to your mobile phone (non-phone devices must reference the device eg dongle, tablet etc) 1.2.3.3 Charge notification must be white text on black background or black text on white background. 1.2.4 Screens, s, iframes and Buttons 1.2.4.1 Follow, with no deviation (except for button colour), the screen, page, and iframe Consumer Experience Flow design options presented in the Scheme Rules 1.2.4.2 All Payforit Payment screens or buttons served into the Merchant environment 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. 1.2.4.3 There must be no interference with the normal function of a browser, buttons must perform as expected. 1.2.4.4 Use the HTML files and CSS files supplied on Payforit.org as reference material in order to create the Consumer Experience Flows. 1.2.4.5 Serve all screen, page, and iframes, with product and pricing information provided by Merchants. 1.2.4.6 It is the API s responsibility to ensure that all clickable hyperlinks and purchase buttons are sufficiently spaced so that a charge cannot be accidently made 1.2.4.7 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. 1.2.4.8 The name of the product / service being purchased must be consistent with the product / service selected by the consumer on the Merchant site 1.2.4.9 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.

15 of 43 Click to go 1.2.4.10 The price must appear on the first call to action button and follow these rules 1.2.4.10.1 One-off payment: Buy Now for <Price> 1.2.4.10.2 One-off charity donation: Donate <Price> Now 1.2.4.10.3 Charity subscription: Donate <Price> Now 1.2.4.10.4 Standard subscription: Subscribe Now for <Price> 1.2.4.10.5 Subscription with initial free period: Subscribe Now free for <Period> and then be charged <Price> 1.2.4.10.6 Subscription with initial charge: Subscribe Now for an initial charge of <Initial Charge> plus <Price> 1.2.4.10.7 Competition: See 8 Double Opt In Flow Specific Rules 1.2.4.11 When the MSISDN is confirmed the charging notification along with the price must appear on the second payment button: Click to confirm you accept that <price> will be charged to this mobile phone or, for subscriptions: Click to confirm you accept that <price> per <Billing Frequency> will be charged to this mobile phone. 1.2.4.12 The price of the product or service must be presented in pounds sterling using the principles; 1.2.4.12.1 If the price is 99p or lower present the pricing in pence e.g. 69p. 1.2.4.12.2 If the price is above 99p use the sign (symbol). 1.2.4.12.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). 1.2.4.12.4 If the pricing is pounds and pence, pricing must be presented as x.xx e.g. 3.99 1.2.4.12.5 Do not allow pricing display that could be misleading e.g. 4* 2 instead of 8 1.2.4.13 Pricing notification must not be deliberately complex. E.g. 2* 2 per 3 days when 4 per 3 days is adequate 1.2.4.14 Call to Action buttons may be presented in a different colour providing that the contrast between text and button colour is contrasting as follows; 1.2.4.14.1 Convert the dominant background colour to HSL (hue, saturation, lightness). 1.2.4.14.2 Present the text in white (#FFFFF) when the lightness is less than 50%. 1.2.4.14.3 Present the text in black (#00000) when the lightness is greater than 50%. 1.2.4.14.4 Present the text in either white or black when the lightness is exactly 50%. 1.2.4.15 All Networks require the Marketing opt-in tick-box to be shown as un-ticked on the second purchase screen. 1.2.4.16 Only the words given in the Scheme Rules are permitted on the Payforit pages. Questions, offers and other text not part of the consent to charge process must not be mixed with the consent to charge on the Payforit payment page. 1.2.4.17 Any pages before the PFI payment pages may not use the Payforit header box, nor anything that approximates to it. The header box attributes are its location, size, quantity of lines of text, and their fonts etc - these must not be used in a replica box.

16 of 43 Click to go 1.2.4.18 The payment button also must not be replicated on preceding pages. The attributes of the button include location, button colour, button size, colour of text, number of lines, length of lines. The button colour and size must never be replicated - and only 2 of the other attributes may be used on previous pages' buttons. 1.2.5 Payment Received Notification 1.2.5.1 The Payment Received Notification Field must state; 1.2.5.1.1 You ve paid <Price> for one-off payments 1.2.5.1.2 You ve donated <Price> for donations 1.2.5.1.3 Your subscription <Price> has been set up and will continue until you text STOP to <Shortcode> for subscription services (or acceptable alternative). 1.2.5.2 Payment Success screens must confirm the charge notification: This will be charged to your next phone bill or deducted from your prepay balance. 1.2.5.3 Payment Success screens must have Continue on the call to action button except for subscriptions where it must say Continue to <service> 1.2.6 Error Rules 1.2.6.1 APIs must include, as a minimum, the error description language on every payment failure screen, page or iframe 1.2.6.2 The same potential errors apply for all MNOs, but some error descriptions vary slightly between Three and the other MNOs. 1.2.6.3 Error Description Language for Three based on error code returned; 1.2.6.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. 1.2.6.3.2 General error: Service temporarily unavailable; try again later. 1.2.6.3.3 Insufficient Funds Web: Top up your mobile phone account by accessing www.three.co.uk/my3 now. 1.2.6.3.4 Insufficient Funds Handset: Top up your mobile phone account by accessing http:\\mobile.three.co.uk/sdf/bmmy3 now. 1.2.6.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. 1.2.6.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. 1.2.6.3.7 MO flow when text not received: Text message not yet received. Click Retry Payment. 1.2.6.3.8 Services bar: Premium rate services are unavailable on your account. Access www.three.co.uk/my3 now for more information. 1.2.6.4 Error Description Language for O2, Orange, T-Mobile, EE & Vodafone; 1.2.6.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. 1.2.6.4.2 General error: Service temporarily unavailable; try again later.

17 of 43 Click to go 1.2.6.4.3 Insufficient Funds: Top up your mobile phone account by accessing [MNO contact number] now. 1.2.6.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. 1.2.6.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. 1.2.6.4.6 MO flow when text not received: Text message not yet received. Click Retry Payment. 1.2.6.4.7 Services bar: Premium rate services are unavailable on your account. Access [MNO contact number] now for more information. 1.2.6.5 Shown with every error description: To contact your mobile phone company, please call [MNO contact number] directly from your mobile 1.2.6.6 MNO Contact numbers are: O2: 202 (contract consumers) or 4445 (prepay consumers), Orange: 150 (contract consumers) or 150 (prepay consumers), T-Mobile: 150, Vodafone: 191, EE: 150 1.2.7 Payment Failure 1.2.7.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. (Subject to specific network requirements) 1.2.8 Payforit Logo 1.2.8.1 Place the Payforit Logo as demonstrated on all Payforit Consumer Experience Flows. 1.2.8.2 Hyperlink the Payforit logo to the About Payforit information screen, page, or iframe on all Payforit screens, pages, and iframes. 1.2.8.3 Use only master versions of the Payforit logo. 1.2.8.4 Apply the Payforit logo to approved product or service only, with no implied affiliations with, or endorsements of, unapproved products or services. 1.2.8.5 Surround the Payforit logo with a clear zone, as defined by the master version of the Payforit logo. 1.2.8.6 Apply the Payforit trademark to approved sites only; refrain from applying the Payforit logo to sites that violate laws or regulations. 1.2.8.7 Employ only the approved Payforit trademark, using no hyphenations, abbreviations, or acronyms. 1.2.8.8 Display the Payforit trademark in a manner that is fair, truthful, positive, and inoffensive to MNOs. 1.2.8.9 Register only the appropriate trademark as a second-level domain name, without referring to the Payforit trademark. 1.2.9 Merchant Logos, Slogans and Designs 1.2.9.1 Present no Merchant logo on Payforit screens, pages, and iframes containing products or services that might bring the Payforit logo into disrepute. 1.2.9.2 Use only logos, slogans, and designs that cannot be confused with the Payforit logo and the Payforit trademark. 1.2.9.3 Present the Merchant logo for mobile with a maximum height of 40 pixels and a maximum width of 180 pixels 1.2.9.4 Present the Merchant logo for Web with a maximum height of 40 pixels and a maximum width of 440 pixels. 1.2.9.5 Use no animation within the Merchant logo.

2 MT (AND HYBRID) FLOW RULES 18 of 43 These rules facilitate compliance with Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR) and PPP 13th Code of Practice The screens in this Consumer Experience Flow 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 or using a separate computer). The consumer explicitly acknowledges their obligation to pay by entering their MSISDN. 3.1 MT Flow Transaction Rules 3.1.1 Consumer must explicitly acknowledge they understand the transaction and consent to charge by entering their MSISDN and clicking Buy Now on the first screen and on the second screen by entering their verification code and clicking to accept the charge. 3.1.2 If the MSISDN is correctly formatted, the API sends a text message to the MSISDN containing a unique Payment Code. 3.1.3 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 3.1.4 If the MSISDN is invalid three times, then the API should consider moving to an MO Flow if supported or cancel the purchase. 3.1.5 Send pricing information in all text messages sent to the consumer, except service delivery text messages. 3.1.6 Send the free to-consumer purchase verification code text message to the MSISDN entered by the consumer. 3.1.7 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 3.1.8 Ensure the purchase verification code expires within 15 minutes of being sent. 3.1.9 Switch the consumer to a MO flow (if supported by API) after three unsuccessful attempts to enter the purchase verification code. 3.1.10 If the code is entered incorrectly and the Call to Action button pressed, the API should present the red error message Enter valid code 3.1.11 If MO flow not supported by API, abandon the transaction after three unsuccessful attempts to enter the purchase verification code. 3.1.12 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.1.13 Ensure purchase verification codes cannot opt the consumer into a different active service (i.e., codes misspelled accidentally must not match the opt-in for another active service on the same shortcode). 3.1.14 Include, optionally, a URL in the purchase verification code text message for Mobile flows that the consumer may click to complete purchase. 3.1.15 Limitations for the URL included in the MT message are; 3.1.15.1 URL may be clicked only within 15 minutes of the message being sent 3.1.15.2 URL must enforce no more than one charge per click 3.1.15.3 URL must not identify the consumer MSISDN directly; a MSISDN alias must be used. 3.1.15.4 URL, once clicked, must take the consumer to the API payment success screen

19 of 43 3.1.15.5 Charge the MSISDN and deliver product if the correct purchase verification code is entered within 15 minutes 3.1.16 Charge only the MSISDN from which the purchase verification code originated and terminated 3.1.17 A dropbox for the consumer to select their own network can be provided. 3.1.18 An optional Don t know your mobile number? link will switch the Consumer Experience Flow from Mobile MSISDN through MT to Mobile MSISDN through MO flow. 3.1.19 If the user clicks the Call to Action button the API must apply the charge to the consumer s mobile network. Based on the response from the network, the API must then: 3.1.19.1 If successful, present the relevant Success Screen or iframe or return the consumer to the Merchant for the product or service delivery and send a text receipt to the consumer 3.1.19.2 If unsuccessful, present the relevant Failure Screen or iframe to the consumer 3.2 MT Flow Screens Mes Receipt FreeMsg: Use code 1598 to verify your purchase of 4 or click this link to complete your transaction < wwwfactorydirect.biz?h askjkj

20 of 43

3 MO FLOW RULES 21 of 43 These rules facilitate compliance with Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR) and PPP 13th Code of Practice 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. The consumer explicitly acknowledges their obligation to pay by texting the code. 4.1 MO Flow Transaction Rules 4.1.1 Consumer must explicitly acknowledge they understand the transaction and consent to charge by clicking Buy Now on the first screen and clicking to send the verification keyword text on the second screen or clicking to activate an IVR. 4.1.2 Use a unique verification code of at least 4 characters that will link the Payforit session with the MO message. 4.1.3 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. 4.1.4 Link the consumer the payment success page for mobile within text message receipts. If the Merchant site cannot support re-entry via a link then the MO method may not be used. 4.1.5 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 4.1.6 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. API must host the short code used to send the MO message to (subject to Network requirements). Virtual numbers are not permitted for MO opt (big numbers 07xxx). 4.1.7 Redirect optionally, to the payment failure screen if the API fails to receive the purchase verification code text message after 15 minutes. 4.1.8 Once the text message containing the correct keyword has been received by the API, the API must apply the charge to the consumer s mobile network. Based on the response from the network, the API must then; 4.1.8.1 If successful, present the relevant 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 4.1.8.2 If unsuccessful, present the relevant Failure Screen to the consumer

4.2 MO Flow Screens 22 of 43

4 MT MO HYBRID FLOW RULES 23 of 43 These rules facilitate compliance with Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR) and PPP 13th Code of Practice 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. The consumer explicitly acknowledges their obligation to pay by entering their MSISDN and a verification code. 5.1 MT MO Hybrid Flow Transaction Rules 5.1.1 Consumer must explicitly acknowledge they understand the transaction and consent to charge by clicking Buy Now on the first screen and entering their MSISDN and texting the relevant code or clicking on a link inside an SMS. 5.1.2 This Consumer Experience Flow requests the MSISDN from the consumer as in 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 5.1.3 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 (or clicking on a link inside an SMS) response request. 5.1.4 The SMS message must contain the price information. 5.1.5 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 5.1.6 If the MSISDN is invalid three times, then the API should consider moving to the MO Flow if supported or cancel the purchase. 5.1.7 Once the correct text message containing the keyword has been received by the API (or link activated), the API must apply the charge to the consumer s mobile network. Based on the response from the network, the API must then: 5.1.7.1 If successful, present the relevant 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 5.1.7.2 If unsuccessful, present the relevant Failure Screen to the consumer 5.1.8 If the response text message is not received in 5 minutes, present the relevant Failure Screen 5.1.9 Use a unique verification code or clicking on a link inside an SMS that will link the Payforit session with the MO message 5.1.10 Charge the MSISDN only if it responds with the keyword within 15 minutes. 5.1.11 Expire verification code or link inside an SMS after 15 minutes and reject transactions that are using expired codes or links. 5.1.12 Ensure the keyword is alphanumeric, with at least one character or clicking on a link inside an SMS 5.1.13 Ignore additional keywords or links sent by the consumer after the verification keyword or link 5.1.14 API must host the short code used to send the MO message to (subject to Network requirements).

5.2 MT MO Hybrid Screens 24 of 43 Message Receipt FreeMsg: Please <click this link/reply Y> to confirm acceptance and this will verify your mobile number if you wish to proceed with your purchase of Superwidges for 4 from FactoryDirect. Help? 0305551234.

IVR Screens 25 of 43

5 WEB FLOW SPECIFIC RULES 26 of 43 The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR) and PPP 13th Code of Practice Consumers must be clearly informed of all information likely to influence the decision to purchase prior to entering a binding contract. Consumer must explicitly acknowledge the obligation to pay with active consent from the consumer. Consumers must not be misled and words must be unambiguous. Web Flows 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 consumer s mobile network. When an API detects that the user is connected via a device that cannot readily 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 doesn t need to re-enter on each purchase. 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.

27 of 43 Click to go 8 DOUBLE OPT IN FLOW SPECIFIC RULES These rules facilitate compliance with Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (CCR) and PPP 13th Code of Practice Consumer expectations about standard of information provided about price and other key items and the positivity of the opt in to these charges must be consistent with the standard. Consumers must be clearly informed of all information likely to influence their decision to purchase prior to entering into a binding contract and must explicitly acknowledge their obligation to pay. Consumers must not be misled and words must be unambiguous.. Providers must not mislead through inclusion of false or confusing information or by omission. Subscription rules apply to recurring payments. 8.1 Double Opt-in Flow Transaction Rules 8.1.1 The API must complete the Double Opt In certification assessment before using the Flow 8.1.2 Both purchase buttons must be clicked to provide the consumer s consent to be charged, and the charge cannot be applied until the second button has been clicked. 8.1.3 Where relevant the API must ensure the consumer is on the website before charging. For example, the consumer should not be charged if they send an MO message for verification and have closed the web session. 8.1.4 For high risk services (network defined, currently adult and competitions) the API is not permitted to pass the MSISDN to the merchant and the merchant must agree to forfeit all rights to the MSISDN when using this service. This includes the MSISDN for marketing purposes. The MSISDN must be identifiable for Customer Service purposes. The merchant may send appropriate marketing communications to the consumer (when permission has been granted) through the API (or other APIs). It is the API s responsibility to ensure all marketing opt out requests are handled appropriately. 8.1.5 Adult services must have an age verification process carried out on entry to the site. If this involves the use of a MSISDN then the API and not the merchant must do it. The user s transaction must be declined if they are not age verified for adult content. For the avoidance of doubt, they are not permitted to be charged and redirected to glamour content. 8.1.6 The API must control the serving of all HTML, CSS, and image content for all payment screens served directly to the consumer. The merchant may not serve any screen that contains any chargeable actions to the consumer outside of the control of the API. Only the API is allowed to control Purchase Buttons on a page and all parameters must be encrypted to ensure robust verification. Additionally all screens controlled by the API must have the source code retained as per Audit Requirements and the API must verify all information appears correctly before displaying the page to the consumer. 8.1.7 When using a proxy system the API must ensure not only the cached images but also the code underneath them is checked and verified. 8.1.8 For high risk services (network defined, currently adult and competitions) the API must record all Customer Service calls received in addition to retaining call logs, 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 6 months. If a consumer enquiry has been escalated, all calls must be retained for 6 months after the case has been closed.

28 of 43 Click to go 8.1.9 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. 8.1.10 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 12 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. 8.1.11 Each page must have a time stamp to log the time spent navigating it and a record of which link on a page was selected to access the next page. 8.1.12 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. 8.1.13 The API must ensure the consumer is only charged ONCE for each item and they cannot be charged for something either already purchased or already purchased and not yet expired. The API must ensure the consumer is on the website before charging and the consumer must be linked the Merchant Service from all mobile payment flows from within the text message receipt. 8.1.14 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 operator s billing policy. 8.1.15 No one service may bill more than 30 in a 24 hour period (or calendar day to API s 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. 8.1.16 The API must send a reminder message for every 20 billed through a recurring payment service or one month whichever is soonest 8.1.17 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. Subsequent Double Opt-in Flow purchases must be at the same price (or lower) until they return to the selection screen. 8.1.18 When the API offers multiple, time limited, purchases such as via paywalls, the minimum period that can be offered is 24 hours. 8.1.19 A 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. All standard PFI Subscription rules must be followed. 8.1.20 Where a service has an initial free period before charging commences the welcome message should be sent immediately instead of a receipt message. 8.1.21 Promotional material must NOT distract from the pricing information. 8.1.22 The API must send a welcome message to the consumer immediately when a subscription is raised. All purchases must be billed immediately and an SMS receipt issued without delay. 8.1.23 The API must host the shortcode used for the STOP command and the API must process any STOP requests immediately. IVRs may be used. 8.1.24 Evidence of service consumption includes:

29 of 43 8.1.24.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; 8.1.24.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 or clicking a link; 8.1.24.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 8.1.25 The API must put an exit link in the header box to allow the consumer to safely exit the page without incurring a charge. 8.1.26 If the consumer is using a wifi connection then an MO/MT/IVR or Hybrid verification method can be used to identify the MSISDN (subject to Network agreement). The consumer should still click the first button, with the verification method replacing the second button. The verification method must uniquely and robustly link to the consumer s browsing session using the rules listed in section C and the consumer should only be charged once they return to the double opt in flow. 8.1.27 The API should ensure that all key information must remain above the fold when the merchant s site is viewed in landscape mode. 8.1.28 If the merchant wishes to collect marketing consent then an un-ticked tick box must be placed in a prominent and proximate position to the second purchase button. This should state Send offers for similar services to my mobile, the consumer only gives marketing permission if the tick box is ticked when the second purchase button is clicked by the consumer.

30 of 43 Click to go Double Opt-in Flow Competitions Message s Receipt FreeMsg: Thanks and good luck! You paid 4.00 for a chance to win an iwatch, Ticket http://winiwatch/1234 HELP? 0305551234 orhttp://factorydirect.biz/content.asp?ui=9155

Double Opt-in Flow Subscriptions 31 of 43 Message s Receipt FreeMsg: Thank you. You have subscribed to Superwidgets for 4.50 per week from Factory Direct until you text STOP to <shortcode> to opt out. HELP? HELP? 0305551234

Double Opt-in Flow Time Ltd Access and One off Purchases 32 of 43

Embedded Double Opt In iframes 33 of 43

8.2 Double Opt-in Flow Screen Rules Double Opt-in Flow Screens (all except Competitions) 34 of 43 8.2.1.1 Purchase buttons are mandated and supplied by the Payforit Management Group and will conform with the following rules: 8.2.1.1.1 Purchase button s width is 270px wide and should be positioned at least 10% away from the edge of the phone s screen this applies to the first and second opt-in buttons 8.2.1.1.2 The buttons have a padding of 10px around all edges, border radius of 10px, central aligned text and no CSS text decoration. 8.2.1.1.3 The button has a vertical padding of 20px and horizontal padding of 10px. Purchase buttons will only contain text and no logos, images or icons 8.2.1.1.4 Text is 12 or 14px font, all bold or no bold, no italic or underlining. All text on the purchase buttons is of the same font colour, size and style. Title casing for the top line with sentence casing for the bottom line is permitted but with no further captialisation. 8.2.1.1.5 Purchase button s text is white or black using the contrast ratio to determine the colour based on the button s background colour 8.2.1.1.6 Purchase button s background colour has a clear contrast to the background colour of the merchant s site that surrounds the button. Background colours must be solid with no gradients, patterns or shadows permitted. 8.2.1.1.6.1 The first purchase button must state either Buy now for x, Donate x now, Deposit x now, Enter now for x, Vote now for x or Subscribe now for x. 8.2.1.1.6.2 The second purchase button must be a different colour (as determined by WCAG 2.0 guidelines http://www.w3.org/tr/wcag20/ with a minimum ratio of 2:1) to the first step opt-in purchase button and remain contrasting to the merchant s background colour that surrounds it. 8.2.1.1.6.3 The second opt-in purchase button s text colour must also use the contrast ratio to determine the colour based on the second opt-in purchase button s background colour. 8.2.1.2 Adjacent text, graphics and logos must not detract from the pricing prominence. There must be at least 10px between any promotion and the price/purchase button. Competition Double Opt-in Rules 8.3 The following requirements supersede rules governing the first purchase button which do not apply if the following rules are followed in their entirety. 8.3.1 The rules covering the second purchase button must be followed. 8.3.2 A competition question must require sufficient skill to answer and be placed immediately above an Answer Box. Additionally, it must not obfuscate, detract or interfere with the Answer Box. 8.3.3 Multiple choice Answer Buttons should appear on a single horizontal line and must be positioned at least 10% away from the edge of the phone s screen, inside the Answer Box.

35 of 43 8.3.4 The text within the Answer Button must not exceed font size 24 and there should be a maximum of 20px padding between the text and the edge of the button. The Answer Button may have a different colour border surrounding it, up to a maximum width of 3px. 8.3.5 The background colour and border for each Answer Button must be the same and should have a clear contrast to the background colour of the merchant s site that surrounds the Answer Box area. Colours should be solid and not contain gradients or textures. 8.3.6 All text on the Answer Button must be of the same font colour, size and style and should not contain any logos, images or icons except where the answer option is to pick between different images, in which case the button should only contain images up to a maximum width of 75px high by 75px wide. 8.3.6.1 The pricing text must be placed inside the Answer Box, directly beneath the horizontal answer buttons and must state either Click to enter and x will be charged to this mobile phone or for a subscription service: Click to enter 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 Click to enter for x.xx per [week/month] after x [Mins Hours Days Weeks Months]. A charge time/date notice must be in the SMS receipt and sending STOP or other termination method before that time no charge is made. 8.3.7 The Pricing Text must be either 12 or 14px font with no italic or underlining. The text must be white or black using the contrast ratio to determine the colour based on the button s background colour. Adjacent text, graphics and logos must not detract from the pricing prominence. 8.3.8 The Answer Box must have a border of sufficient contrast to clearly group the Answer Buttons and Pricing Text. This border should be at least 2px wide and less than 4px and should not have a gap of more than 20px from the answer buttons or Pricing Text 8.3.9 If the incorrect answer is selected there should be an option to return to the question on the answer page to allow the consumer to change their answer before the second purchase button has been clicked. 8.3.10 After entering a competition, the consumer must be taken to a confirmation page which indicates they have successfully entered the competition. To get to the next competition the consumer should press Next Competition button on the relevant Success. There must be no promotional information on this page. Any additional competition promotions should clearly indicate this is a separate competition and must start on a new page that is not the confirmation page, with manual navigation by the consumer to select the option of entering another competition. 8.3.11 If a website contains multiple competitions it must maintain a clear tally of competitions entered and each competition must be billed immediately and the SMS Receipt sent immediately. 8.4 Embedded iframes 8.5 The double opt in single purchase and subscription flow may be used inside an iframe, embedded on a merchant s website (the competition flow may not be used due to the positioning of the pricing information). 8.6 When using Embed Method the Payforit information becomes part of the Merchant s 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. The Embed flow must be used within an environment where iframe masking is not technically possible.

36 of 43 Click to go 8.7 Any pages before the PFI payment may not use the Payforit header box, nor anything that approximates to it. The header box attributes are its location, size, location, quantity of lines of text, and their fonts etc - these must not be used in a replica box. The payment button also must not be replicated on preceding pages. The attributes of the button include location, button colour, button size, colour of text, number of lines, length of lines. The button colour and size must never be replicated - and only 2 of the other attributes may be used on previous pages' buttons. API should deploy ongoing risk assessment and controls to ensure that their Merchants continue to comply with this requirement. 8.8 The header box must appear at the top of the iframe, with the Purchase Buttons appearing underneath it. The iframe must be a minimum size of 300 pixels (width) by 200 pixels (height). These sizes can be increased proportionally but the iframe must not occupy more than 80% of the available screen display 8.9 The API must ensure the entire header box, purchase buttons and service information is shown correctly and has not been tampered or obscured by a third party. 8.10 An iframe approach must not be used for co-registration competition consumer journeys

37 of 43 Click to go 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 as evidence of a contract in a durable medium within a reasonable time. This is to ensure that the consumer is kept fully informed during their purchasing journey and they are able to demonstrate active consent to charge. 1. Every Charge requires an immediate free-to-consumer purchase receipt text message using mandated language provided for the various transaction types unless otherwise stated. 2. 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. 3. 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. 4. 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 they ve already purchased. Messages must detail a marketing opt-out facility. 5. 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. 6. All MT messages must be free to the receiver and be routed through the consumer s mobile network. All MO messages must be standard network rate or less. 7. If an alternate mobile number is provided the receipt message must be sent from the network of that number. 8. When an 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 doesn t need to re-enter on each purchase. 9. Link the consumer the payment success screen, page, iframe or Merchant Service for all mobile payment flows from within the text message receipt. 10. 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 11. APIs must use specific language for each text message for each consumer event in the table below unless the Payforit Management Group has permitted a variation. Although some text messages are optional, all text messages, without deviation, must include the mandated language or information shown. APIs

38 of 43 Click to go may add information to the mandated language ONLY with the permission of the Payforit Management Group. The Payforit Management Group has agreed that a positive affirmation for competition entries is permitted. 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. EVENT TEXT MESSAGE LANGUAGE WHEN TO SEND SENDER ADDRESS 1. Consumer completes Payforit 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 2. Consumer completes charity mobile purchase process; mandatory delivery of free text message receipt. FreeMsg: Thank you for your donation of <price in > for <charity name>. HELP? <UK standard rate or free helpline number>. Immediately Receipt 3. Consumer completes Payforit Purchase process via a tablet or other non phone device that cannot support shortcode SMS; mandatory delivery of receipt via email. Thank you for your payment of <price in > for <product or service name> from <Merchant>. HELP? <UK standard rate or free helpline number>. Immediately Ensure email address is not blocked 4. 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 As Rule 10 5. 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>. Immediately Receipt As Rule 10

EVENT TEXT MESSAGE LANGUAGE WHEN TO SEND SENDER ADDRESS 39 of 43 6. Consumer opts into subscription with initial charge; mandatory delivery of free subscription opt-in text message 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>. Immediately Receipt As Rule 10 7. Consumer opts into alerts-based subscription; mandatory delivery of free subscription opt-in text message receipt. FreeMsg: You are subscribed to <service name> for <price in > per <event> until you text STOP to <shortcode>. HELP? <UK standard rate or free helpline number>. Immediately Shortcode 8. Consumer opts into alerts-based 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 <event> from <date> unless you text STOP to <shortcode>. HELP? <UK standard rate or free helpline number>. Immediately Shortcode 9. Consumer opts into subscription; mandatory delivery of free subscription/spend reminder. FreeMsg: Reminder. Thanks 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 As Rule 10 10. Consumer requests code within Web MT payment flow; delivery of MSISDN verification code text message. FreeMsg: Use code <code> to verify your <purchase/donation> of <price in >. Immediately Receipt 11. 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

EVENT TEXT MESSAGE LANGUAGE WHEN TO SEND SENDER ADDRESS 40 of 43 12. 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 13. Consumer purchases one-off product via MT-MO hybrid payment flow; delivery of opt in text message. FreeMsg: Please <click this link/reply Y> to confirm acceptance and this will verify your mobile number if you wish to proceed with your purchase of <price in > from <Merchant>. Help? <UK standard rate or free helpline number>. FreeMsg: Please <click this link/reply Y> to confirm acceptance and this will verify your mobile number if you wish to proceed with your subscription of <price in > per <billing frequency> from <Merchant>. Help? <UK standard rate or free helpline number>. Immediately Shortcode 14. Consumer subscribes via MT-MO hybrid payment flow; delivery of opt-in text message. Immediately Shortcode 15. Consumer subscribes via MT-MO hybrid payment flow; delivery of opt-in text message. FreeMsg: Please <click this link/reply Y> to confirm acceptance and this will verify your mobile number if you wish to proceed with your subscription of <price in > per <billing frequency> from <Merchant>. Help? <UK standard rate or free helpline number>. Immediately Shortcode 16. Consumer completes Double Opt-in Flow 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> or view again at [url] Immediately Receipt

EVENT TEXT MESSAGE LANGUAGE WHEN TO SEND SENDER ADDRESS 41 of 43 17. Consumer opts into Double Opt-in Flow recurring payments with initial free period; mandatory delivery of optout and receipt information. FreeMsg: You have subscribed to <service name> for <price in > per <week month> from <charge date> until you text STOP to <shortcode> to opt out. HELP? <Helpline number> Immediately Receipt 18. Consumer opts into Double Opt-in Flow recurring payment; mandatory delivery of free text message receipt. FreeMsg: Thank you. You have subscribed to <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 19. Consumer opts into Double Opt-in Flow recurring payment; mandatory delivery of spend reminder. FreeMsg: Reminder. You subscribed to <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 20. Consumer opts into Double Opt-in Flow Competition FreeMsg: Thanks and good luck! You paid <price> for a chance to win <prize>, <Merchant> <Competition terms> HELP? <UK standard rate or free helpline number> orhttp://factorydirect.biz/content.asp?ui=9155 FreeMsg: <Merchant> seems to have lost you. To access their site again please click <Merchant URL>. Immediately Receipt 21. Consumer abandons checkout voluntarily or through loss of service; optional delivery of free service delivery text message. Within 15 minutes Receipt 22. 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

42 of 43 Click to go EVENT TEXT MESSAGE LANGUAGE WHEN TO SEND SENDER ADDRESS 23. 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 Receipt 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 12 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

43 of 43 Click to go Please note that individual MNO contracts may extend the 12 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 API s 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 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 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. consumer complaint facilities must not use 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.