PAYFORIT SCHEME RULES TRANSA PAYFORIT SCHEME RULES 5.0

Transcription

1 5.0 1 of 43 Version Control: Date Changes Payforit Scheme Rules CCR May 15 1 Sept 15 PUBLISHED 1 ST SEPTEMBER 2015 Pre CCR see Full Document filed on the website for legacy 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 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 NB Success and Failure screens may have been removed from the illustration to save space. They are still required as per the rules.

2 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 All Flows Transaction Rules Payforit Session MSISDN Handling Subscriptions and recurring payments Common Screen Items and Style Rules Header Box Merchant Detail Charge Notification Screens, s, iframes and Buttons Payment Received Notification Error Rules Payment Failure Payforit Logo... 17

3 3 of 43 Click to go Merchant Logos, Slogans and Designs MT (and Hybrid) Flow Rules MT Flow Transaction Rules MT Flow Screens MO Flow Rules MO Flow Transaction Rules MO Flow Screens MT MO Hybrid Flow Rules MT MO Hybrid Flow Transaction Rules MT MO Hybrid Screens Web Flow Specific Rules Double Opt In Flow Specific Rules Double Opt-in Flow Transaction Rules Double Opt-in Flow Screen Rules Section E - Text Message Mandated Language Section F - Audit Log Requirements Section G Customer Service Requirements... 43

4 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 ). 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 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 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 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 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 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 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 Payforit Session 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 Charge the MSISDN only once per session Send text receipt message once charge has been made. See Section E - Text Message Mandated Language 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 Merchant must supply consumer with their product or service immediately after purchase completion and successful billing 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 address can use click to " Smartphone function The Help links for Merchant and Payforit terms must be separate 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 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 9 of 43 Click to go MSISDN Handling 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 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 In all other cases, APIs must safeguard consumer MSISDNs from Merchants and other APIs 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) 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 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 MT VERIFICATION METHOD Generate a random code of 4 or more alphanumeric characters A code used in the previous 5000 transactions may not be selected The SMS message must start with FreeMSG and make it clear the user is verifying their purchase intent If the MSISDN is invalid three times, then the API should consider moving to an MO Flow if supported or cancel the purchase Send pricing information in all text messages sent to the consumer, except service delivery text messages Send the free to-consumer purchase verification code text message to the MSISDN entered by the consumer 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 Ensure the purchase verification code expires within 15 minutes of being sent Switch the consumer to a MO flow (if supported by API) after three unsuccessful attempts to enter the purchase verification code If MO flow not supported by API, abandon the transaction after three unsuccessful attempts to enter the purchase verification code 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) 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) Include, optionally, a URL in the purchase verification code text message for Mobile flows that the consumer may click to complete purchase Limitations for the URL included in the MT message are; URL may be clicked only within 15 minutes of the message being sent URL must enforce no more than one charge per click

10 10 of URL must not identify the consumer MSISDN directly; a MSISDN alias must be used URL, once clicked, must take the consumer to the API payment success screen Charge the MSISDN and deliver product if the correct purchase verification code is entered within 15 minutes Charge only the MSISDN from which the purchase verification code originated and terminated A dropbox for the consumer to select their own network can be provided MO AUTHENTICATION METHOD Use a unique verification code of at least 4 characters that will link the Payforit session with the MO message 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 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 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. 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) HYBRID AUTHENTICATION METHOD The SMS message must contain the price information The SMS message must start with FreeMSG and make it clear the user is verifying their purchase intent 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 If the response text message is not received in 5 minutes, present the relevant Failure Screen Use a unique verification code or clicking on a link inside an SMS 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 or link inside an SMS after 15 minutes and reject transactions that are using expired codes or links Ensure the keyword is alphanumeric, with at least one character or clicking on a link inside an SMS Ignore additional keywords or links sent by the consumer after the verification keyword or link API must host the short code used to send the MO message to (subject to Network requirements) IVR AUTHENTICATION METHOD The consumer must be made aware of the call duration and cost prior to calling

11 11 of Only standard rate or less IVR numbers may be used An IVR line must be randomly selected from a pool of at least 400 numbers The IVR numbers and termination point must be controlled by the API 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 Once an IVR line has been presented it must not be reused for at least 30 minutes The consumer must call the IVR line within 15 minutes of it being presented otherwise the authentication should be rejected Subscriptions and recurring payments Price and duration must be clear and prominent directly before the order in large, legible font A simple method of termination (STOP unless otherwise agreed with MNO) of the service must be clearly informed before the order is made API must send a free to-consumer subscription initiation receipt message (text or ) 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 ) messages every month or every 20 (including VAT), whichever happens first API must support the termination method and the shortcode to which it is sent 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 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 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 See Consumer Experience Flows for any additional requirements

12 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 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 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 Header Box The header box is mandated and supplied by the Payforit Management Group and must be static (floating) 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 No other form of header box using a similar style is permitted on the promotional pages The header box will contain the following items: Payforit logo and merchant terms links MNO logos as shown Exit button Help details Merchant Detail Can carry either the Merchant Brand or the Merchant Name and must be recognisable from the consumer journey to this screen Merchant Detail on unbranded payment flows, must; Contain the name of the Merchant, recognisable from the prior part of the consumer s journey; Contain the word From when the transaction is a purchase E.g. From Factory Direct ; Contain the word To when the transaction is a donation. To Children in Need The name of the Merchant must be the same name used in text receipts Charge Notification

14 14 of 43 Click to go 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: One-off payment: Buy < product / service > One-off charity donation: Donate to <charity name> Charity subscription: Donate to <charity name> per <Billing Frequency> until you text STOP to <shortcode> Standard subscription: Subscribe to < product / service > per <Billing Frequency> until you text STOP to <shortcode> Subscription with initial free period: Subscribe to < product / service > free for <Period> and then be charged per <Billing Frequency> 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 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) Charge notification must be white text on black background or black text on white background Screens, s, iframes and Buttons Follow, with no deviation (except for button colour), the screen, page, and iframe Consumer Experience Flow design options presented in the Scheme Rules 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 There must be no interference with the normal function of a browser, buttons must perform as expected 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 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 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 The name of the product / service being purchased must be consistent with the product / service selected by the consumer on the Merchant site 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 15 of 43 Click to go The price must appear on the first call to action button and follow these rules One-off payment: Buy Now for <Price> One-off charity donation: Donate <Price> Now Charity subscription: Donate <Price> Now Standard subscription: Subscribe Now for <Price> Subscription with initial free period: Subscribe Now free for <Period> and then be charged <Price> Subscription with initial charge: Subscribe Now for an initial charge of <Initial Charge> plus <Price> Competition: See 8 Double Opt In Flow Specific Rules 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 The price of the product or service must be presented in pounds sterling using the principles; If the price is 99p or lower present the pricing in pence e.g. 69p If the price is above 99p use the sign (symbol) 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) If the pricing is pounds and pence, pricing must be presented as x.xx e.g Do not allow pricing display that could be misleading e.g. 4* 2 instead of Pricing notification must not be deliberately complex. E.g. 2* 2 per 3 days when 4 per 3 days is adequate Call to Action buttons may be presented in a different colour providing that the contrast between text and button colour is contrasting as follows; Convert the dominant background colour to HSL (hue, saturation, lightness) Present the text in white (#FFFFF) when the lightness is less than 50% Present the text in black (#00000) when the lightness is greater than 50% Present the text in either white or black when the lightness is exactly 50% All Networks require the Marketing opt-in tick-box to be shown as un-ticked on the second purchase screen 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 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 16 of 43 Click to go 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 Payment Received Notification The Payment Received Notification Field must state; You ve paid <Price> for one-off payments You ve donated <Price> for donations Your subscription <Price> has been set up and will continue until you text STOP to <Shortcode> for subscription services (or acceptable alternative) Payment Success screens must confirm the charge notification: This will be charged to your next phone bill or deducted from your prepay balance Payment Success screens must have Continue on the call to action button except for subscriptions where it must say Continue to <service> Error Rules APIs must include, as a minimum, the error description language on every payment failure screen, page or iframe The same potential errors apply for all MNOs, but some error descriptions vary slightly between Three and the other MNOs Error Description Language for Three based on error code returned; Adult services bar: This service is restricted to users 18 and older. If you are 18 or older, access party to verify your age General error: Service temporarily unavailable; try again later Insufficient Funds Web: Top up your mobile phone account by accessing now Insufficient Funds Handset: Top up your mobile phone account by accessing now 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 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 MO flow when text not received: Text message not yet received. Click Retry Payment Services bar: Premium rate services are unavailable on your account. Access now for more information Error Description Language for O2, Orange, T-Mobile, EE & Vodafone; 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 General error: Service temporarily unavailable; try again later.

17 17 of 43 Click to go Insufficient Funds: Top up your mobile phone account by accessing [MNO contact number] now 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 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 MO flow when text not received: Text message not yet received. Click Retry Payment Services bar: Premium rate services are unavailable on your account. Access [MNO contact number] now for more information Shown with every error description: To contact your mobile phone company, please call [MNO contact number] directly from your mobile 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: Payment Failure 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) Payforit Logo Place the Payforit Logo as demonstrated on all Payforit Consumer Experience Flows Hyperlink the Payforit logo to the About Payforit information screen, page, or iframe on all Payforit screens, pages, and iframes Use only master versions of the Payforit logo Apply the Payforit logo to approved product or service only, with no implied affiliations with, or endorsements of, unapproved products or services Surround the Payforit logo with a clear zone, as defined by the master version of the Payforit logo Apply the Payforit trademark to approved sites only; refrain from applying the Payforit logo to sites that violate laws or regulations Employ only the approved Payforit trademark, using no hyphenations, abbreviations, or acronyms Display the Payforit trademark in a manner that is fair, truthful, positive, and inoffensive to MNOs Register only the appropriate trademark as a second-level domain name, without referring to the Payforit trademark Merchant Logos, Slogans and Designs 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.

18 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 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 If the MSISDN is correctly formatted, the API sends a text message to the MSISDN containing a unique Payment Code 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 If the MSISDN is invalid three times, then the API should consider moving to an MO Flow if supported or cancel the purchase Send pricing information in all text messages sent to the consumer, except service delivery text messages Send the free to-consumer purchase verification code text message to the MSISDN entered by the consumer 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 Ensure the purchase verification code expires within 15 minutes of being sent Switch the consumer to a MO flow (if supported by API) after three unsuccessful attempts to enter the purchase verification code If the code is entered incorrectly and the Call to Action button pressed, the API should present the red error message Enter valid code If MO flow not supported by API, abandon the transaction after three unsuccessful attempts to enter the purchase verification code 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) 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) Include, optionally, a URL in the purchase verification code text message for Mobile flows that the consumer may click to complete purchase Limitations for the URL included in the MT message are; URL may be clicked only within 15 minutes of the message being sent URL must enforce no more than one charge per click URL must not identify the consumer MSISDN directly; a MSISDN alias must be used URL, once clicked, must take the consumer to the API payment success screen

19 19 of Charge the MSISDN and deliver product if the correct purchase verification code is entered within 15 minutes Charge only the MSISDN from which the purchase verification code originated and terminated A dropbox for the consumer to select their own network can be provided 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 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: 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 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 20 of 43

21 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 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 Use a unique verification code of at least 4 characters that will link the Payforit session with the MO message 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 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 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. 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) Redirect optionally, to the payment failure screen if the API fails to receive the purchase verification code text message after 15 minutes 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; 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 If unsuccessful, present the relevant Failure Screen to the consumer

22 4.2 MO Flow Screens 22 of 43

23 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 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 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 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 The SMS message must contain the price information 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 If the MSISDN is invalid three times, then the API should consider moving to the MO Flow if supported or cancel the purchase 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: 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 If unsuccessful, present the relevant Failure Screen to the consumer If the response text message is not received in 5 minutes, present the relevant Failure Screen Use a unique verification code or clicking on a link inside an SMS 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 or link inside an SMS after 15 minutes and reject transactions that are using expired codes or links Ensure the keyword is alphanumeric, with at least one character or clicking on a link inside an SMS Ignore additional keywords or links sent by the consumer after the verification keyword or link API must host the short code used to send the MO message to (subject to Network requirements).