Rules and Regulation

To keep consumers safe, the technology we use is governed by these rules

Transaction Rules


The API must record all Customer Service calls (in line with all relevant  regulations) received in addition to retaining call logs, as required in the Payforit 4 scheme rules. All call recordings must be analysed by the API (i.e. by listening to the recording) on a weekly basis for any consumer grievances and be immediately investigated with the merchant.


All call recordings must be retained for a minimum of 12 months. If consumer enquiry has been escalated, all calls must be retained for six months after the case has been closed.


If the quantity of calls relative to the total number of service users increases by more than 10% in a 7 day period then the API must suspend the service until the cause is identified and rectified.


Consumers must not be charged more than £30 per 24 hours or calendar day as nominated by the API for all services consumed through a single merchant's service.


It is recommended that the API send the following free to user message to the consumer for each and every £100 spent in a calendar month (from: Payforit). This must be sent using the same network for internal audit trail purposes. Message: "FreeMsg: You have spent £ [month total] with [merchant] this month. This is not a subscription service and will appear as [descriptor] on your bill."


To keep a full record of the users consent for the service, the API must retain the HTML source code of every merchant page the consumer interacts with for 24 months. For clarification, this means the HTML and CSS for each page impression and image and not a template version of a page. The API does NOT need to store the purchased content.


Each page must have a time stamp to log the time visited and a record of which purchase button on a page was selected to initiate a purchase.


The API is not permitted to pass the MSISDN to the merchant under any scenario and the merchant must agree to forfeit all rights to the MSISDN when using this service. This includes the MSISDN for Customer Service and marketing purposes. MSISDNs can be submitted to the Merchant to resolve a one on one customer care contact.


The API may pass the merchant an alias to identify the consumer for Customer Service purposes and the merchant may send appropriate marketing communication to the consumer (when permission has been granted) through the API. It is the API's responsibility to ensure all marketing opt out requests are handled appropriately.


If an age verification process is carried out on entry to the site that involves the use of a MSISDN it must be done by the API and not the merchant. (Standard MNO AV policies apply).


The consumer may only be charged the full tariff amount displayed on screen and not multiple amounts to reach the price point advertised, unless this has been permitted by the network operators' billing policy. Any re-tries of a transaction that have failed for insufficient credit or any other reason must conform to the network operator re-try policy.


Only the API is allowed to place Purchase Buttons on a page and all parameters must be encrypted to ensure robust verification.


For time-based access, the API must ensure the consumer is only charged ONCE and that they cannot be charged for access already purchased and not yet expired.


When the API offers time-based access, the minimum period that can be offered is 24 hours.


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.


The API must control the serving of all HTML and CSS content for all screens served directly to the consumer (including the selection and delivery screen). The merchant may not serve any screen that contains any chargeable actions to the consumer outside of the control of the API. Additionally all screens controlled by the API must have the source code retained for 24 months as per Audit Requirements.


The API must complete the Payforit certification assessment before using Double Opt-In Payments Flow.


The API must put an exit link on the page to allow the consumer to safely exit the page without incurring a charge.


The API must offer a 10 minute trial period for any service containing sexual adult visual content by suspending billing for that item until the expiry of 10 minutes and must also display the text: "This mobile will be charged (£price) because a selection was made on the previous screen. If you are not satisfied, you may cancel this charge by clicking here before [time]". This must be placed on a page hosted by the API and shown to the consumer immediately after the purchase has taken place.


If the consumer elects to cancel the charge, the current and all prior suspended billing transactions within the last 10 minutes are cancelled. The receipt for any purchases successfully charged is aggregated and sent immediately.


If the consumer elects to cancel the charge, then the API can (optionally) prevent the consumer from making subsequent purchases. In this case, the API must route the consumer away from the service.


If the consumer is using a wifi connection then an MO can be received instead of clicking a purchase button to improve the user experience and to enable better transaction processing. The MO must be uniquely and robustly linked to the consumer's browsing session.

Recurring Payments

The service may offer a recurring payment option of weekly or monthly frequency and must abide by PhonepayPlus requirements for services charging over £4.50 per week.


The service may have an initial free period before charging commences. When a free period is used the welcome message should be sent immediately instead of a receipt message.


The API must send a welcome message to the consumer immediately.


The API must send a reminder message for every £20 billed or one month whichever is soonest.


The API must host the shortcode used for the STOP command and the API must process any STOP requests immediately.


Permitted evidence for robust service consumption is:


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.


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.


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.

Design Rules


The header box is a minimum height of 28px or 7% of the screen (whichever is greater) and is in proportion with the rest of the screen. It should float at the top of the screen if the user scrolls the page.


The marketing opt in box is always required on the first page if marketing permission is requested. It may be omitted if the marketing opt in is not permitted but the header box must remain above the minimum size.


A cancel box (for sexual adult services) must appear at the top of the screen on the page immediately following the purchase button page. This is to allow the message to remain on the screen when the handset is in landscape mode.


If the advertising for the service has any indication that some content is free (including metatags) then a link shall be provided by the API to the free content and placed in a prominent position above the fold.

Exit link

The exit link must state "Click here to exit website" and be prominent to the purchase button when there is only one payment option per page. If there are multiple purchase buttons on the page then the exit link must be in the Payforit header box.


If the purchase button is above the fold then the exit link must also be above the fold. The exit link must be at least 30px away from the purchase button to avoid accidental clicks.


The exit link must be a contrasting colour to the background of the page and at least a font size of 12px and not be obfuscated.


Purchase Button - The API must ensure that:


Only the purchase button may be clicked to provide the consumer's consent to be charged.


Purchase button's width is not greater than 80% of the screen width and it 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.


The top and bottom border of the purchase button does not have more than 15px padding from the purchase button's text.


Purchase button's background colour has a clear contrast to the background colour of the merchant site that surrounds the button.


All text on a purchase button must be of the same font colour and style. All text must be at least font size 12px. The use of italic and underlining is not permitted. However, the top line of text may be in bold provided it does not detract from the pricing prominence. Adjacent text, graphics and logos must not detract from the pricing prominence.


Purchase button's text is white or black using the contrast ratio to determine the colour based on the button's background colour.


The purchase button only contains text and no logos, images or icon.


There is a clear spacing around the Purchase Button and that any adjacent images or text do not detract from the Purchase Button.


The second opt-in purchase button must be a different colour to the first step opt-in purchase button and remain contrasting to the merchant's background colour that surrounds it. 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.


The call to action wording forming the first line of the button on both purchase buttons may be specified by the merchant but must only be one line and not contain any obfuscation text. It must be verified and placed on the button by the API and the merchant must not have any capacity to interfere with it.


The text on the first opt-in purchase button must start with get, buy or donate and clearly describe any terms of the purchase, for example "get 7 day's access". If a recurring payment option is being used then the call to action text must start with the word "Join".


The second opt-in purchase button call to action should not mislead the consumer and must make it clear they need to click to confirm the purchase, for example Enter?


The second line of the first opt in purchase button must state either "Buy now for £x.xx" or "Join now for £x.xx per [week/month]". If a free period is being offered before any recurring payments take place then this must be clearly communicated to the consumer using "Join now for £x.xx per [week/month] after x [Hours | Days | Weeks]".


The second line of the second opt-in purchase button must state "The charge will go onto this mobile bill".


The second line of text on both purchase buttons must be at least 50% of the size of the first line of text (the call to action line) immediately above it and not less than 12px.


There must be no spacing or distortion of text between the first and second line of text.


The pricing display must follow the principles set out in Section D Sub-Section 3of the Payforit scheme rules and the actual price and £ sign must be in bold.

Still unsure?

Feel free to get in touch via the contact page.

Alternatively email us at

Or call us on
0207 099 2450