{"__v":22,"_id":"5524f5bdd919032b0057ac40","api":{"auth":"required","params":[],"results":{"codes":[]},"settings":"","url":""},"body":"This API document covers ImpulsePay's PaymentPage, which is governed by the Payforit scheme rules and regulated by PhonepayPlus. \n\nPaymentPage is a highly customisable payment flow that allows consumers to purchase one-off or time-based access to services or promotions, virtual goods or service credits, priced between £1 and £30.\n\nSetting up a PaymentPage is the easiest, quickest and most efficient way to start using mobile billing with ImpulsePay. Features of the flow include:\n\n- **Online payment configuration pages** and a **Payment Page Editor** to make setting up new payment pages fast and straightforward.\n\n- The Editor is **based on a compliance upfront** model to approve new payment pages quickly.\n\n- **Faster loading times **for payment pages, with no redirects before getting to the payment page.\n\n- **'Responsive' Payment page for Wifi and 3G users**. Wifi users no longer have to be forwarded to a separate service. New responsive buttons enable merchants to focus on one payment page which can be used by both traffic types.\n\n-**Dynamic content** on payment pages. Subject to prior approval with ImpulsePay, merchants are able to change certain page elements dynamically before the page is loaded to the consumer. \n\n- **A/B split testing of Payment pages**. Merchants who wish to test which payment page designs convert best can now select two alternative page designs to display to end users for a single service, with dashboard statistics available to help measure performance. \n\n- **Recurring Payments** (RPs) enabling merchants to regularly bill consumers based on a pre-defined billing frequency and time period.\n\n- ** Device Agnostic ** to enable payments to be taking easily from desktops, tablets, iPhones, Androids and other mobile handsets.","category":"5524f5bcd919032b0057ac34","createdAt":"2015-02-23T14:24:58.038Z","excerpt":"This API covers the concepts and functionality of an ImpulsePay PaymentPage","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":0,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"introduction-to-paywall-flow","sync_unique":"","title":"Introduction","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Introduction

This API covers the concepts and functionality of an ImpulsePay PaymentPage

This API document covers ImpulsePay's PaymentPage, which is governed by the Payforit scheme rules and regulated by PhonepayPlus. PaymentPage is a highly customisable payment flow that allows consumers to purchase one-off or time-based access to services or promotions, virtual goods or service credits, priced between £1 and £30. Setting up a PaymentPage is the easiest, quickest and most efficient way to start using mobile billing with ImpulsePay. Features of the flow include: - **Online payment configuration pages** and a **Payment Page Editor** to make setting up new payment pages fast and straightforward. - The Editor is **based on a compliance upfront** model to approve new payment pages quickly. - **Faster loading times **for payment pages, with no redirects before getting to the payment page. - **'Responsive' Payment page for Wifi and 3G users**. Wifi users no longer have to be forwarded to a separate service. New responsive buttons enable merchants to focus on one payment page which can be used by both traffic types. -**Dynamic content** on payment pages. Subject to prior approval with ImpulsePay, merchants are able to change certain page elements dynamically before the page is loaded to the consumer. - **A/B split testing of Payment pages**. Merchants who wish to test which payment page designs convert best can now select two alternative page designs to display to end users for a single service, with dashboard statistics available to help measure performance. - **Recurring Payments** (RPs) enabling merchants to regularly bill consumers based on a pre-defined billing frequency and time period. - ** Device Agnostic ** to enable payments to be taking easily from desktops, tablets, iPhones, Androids and other mobile handsets.
This API document covers ImpulsePay's PaymentPage, which is governed by the Payforit scheme rules and regulated by PhonepayPlus. PaymentPage is a highly customisable payment flow that allows consumers to purchase one-off or time-based access to services or promotions, virtual goods or service credits, priced between £1 and £30. Setting up a PaymentPage is the easiest, quickest and most efficient way to start using mobile billing with ImpulsePay. Features of the flow include: - **Online payment configuration pages** and a **Payment Page Editor** to make setting up new payment pages fast and straightforward. - The Editor is **based on a compliance upfront** model to approve new payment pages quickly. - **Faster loading times **for payment pages, with no redirects before getting to the payment page. - **'Responsive' Payment page for Wifi and 3G users**. Wifi users no longer have to be forwarded to a separate service. New responsive buttons enable merchants to focus on one payment page which can be used by both traffic types. -**Dynamic content** on payment pages. Subject to prior approval with ImpulsePay, merchants are able to change certain page elements dynamically before the page is loaded to the consumer. - **A/B split testing of Payment pages**. Merchants who wish to test which payment page designs convert best can now select two alternative page designs to display to end users for a single service, with dashboard statistics available to help measure performance. - **Recurring Payments** (RPs) enabling merchants to regularly bill consumers based on a pre-defined billing frequency and time period. - ** Device Agnostic ** to enable payments to be taking easily from desktops, tablets, iPhones, Androids and other mobile handsets.
{"__v":24,"_id":"5524f5bdd919032b0057ac41","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"A single PaymentPage works seamlessly over both mobile data and wifi connections. The Dashboard allows merchants to easily customise their payment pages and configure services online. \n\nMerchants are able to configure multiple payment pages for a single service (to cater for different designs on desktop, iPhone, Android, iPad and generic mobile devices), upload their own HTML/CSS designs and also set up A/B testing to see which designs convert best on individual devices. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"On a mobile data connection\"\n}\n[/block]\nOn a mobile data connection, a typical consumer experience would be as follows:\n\nThe consumer would gain access to the service using the **Service URL**. They would then be shown to the Merchant's payment page, which ImpulsePay host. This page is presented to the consumer with the **Payforit header box** and the **purchase button** contained on the page. \n\nAt this stage, ImpulsePay have obtained the consumer's **MSISDN **to enable billing directly to that consumer's mobile bill. \n\nThe consumer is then able to make a purchase, opt-in or out of further marketing using a tick box in the Payforit header, or exit the service without charge using the exit link contained in the Payforit header. The consumer can complete a purchase using the two step purchase button. \n\nDepending on the outcome of the purchase, the consumer will be either forwarded to the success URL or redirected to the failure URL, both of which the merchant provides on the Config page.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"On a mobile wifi data connection\"\n}\n[/block]\nOn a Wifi data connection, the consumer experience differs only slightly to that of a mobile data connection, as follows:\n\nThe consumer would gain access to the service using the **Service URL**. They would then be shown to the Merchant's payment page, which ImpulsePay host. This page is presented to the consumer with the **Payforit header box** and the **purchase button** contained on the page. \n\nAs it is not possible to detect a MSISDN over a Wifi connection, when the consumer clicks the purchase button once, a prompt will appear within the button asking the consumer to click and call the automated verification number, which ImpulsePay provides. \n\nOnce the consumer has made the 3 second call to the IVR system, ImpulsePay have verified the MSISDN and the billing attempt is made.\n\nDepending on the outcome of the purchase, the consumer will be either forwarded to the success URL or redirected to the failure URL, both of which the merchant provides.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"On a desktop\"\n}\n[/block]\nOn a desktop, the user's consumer experience differs only slightly to that of a mobile data connection, as follows:\n\nThe consumer would gain access to the service using the **Service URL**.\n\nThey would then be shown to the payment page, which ImpulsePay host. This page is presented to the consumer with the **Payforit header box** and the **purchase button** contained on the page. \n\nAs it is not possible to detect a MSISDN over a Wifi connection, when the consumer clicks the purchase button once, a prompt will appear within the button asking the consumer to insert their phone number and press 'Next'. \n\nThe consumer will then receive a verification text message to their mobile from ImpulsePay asking them to click a link to confirm the purchase. \n\nThe desktop payment page will then update depending on the outcome of the purchase.  The consumer will be either forwarded to the success URL or redirected to the failure URL, both of which the merchant provides.","category":"5524f5bcd919032b0057ac34","createdAt":"2015-02-23T14:25:36.938Z","excerpt":"An introduction to the PaymentPage user experience and general functionality","githubsync":"","hidden":false,"isReference":false,"link_external":false,"link_url":"","order":1,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"service-flow--key-elements","sync_unique":"","title":"Typical Usage","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Typical Usage

An introduction to the PaymentPage user experience and general functionality

A single PaymentPage works seamlessly over both mobile data and wifi connections. The Dashboard allows merchants to easily customise their payment pages and configure services online. Merchants are able to configure multiple payment pages for a single service (to cater for different designs on desktop, iPhone, Android, iPad and generic mobile devices), upload their own HTML/CSS designs and also set up A/B testing to see which designs convert best on individual devices. [block:api-header] { "type": "basic", "title": "On a mobile data connection" } [/block] On a mobile data connection, a typical consumer experience would be as follows: The consumer would gain access to the service using the **Service URL**. They would then be shown to the Merchant's payment page, which ImpulsePay host. This page is presented to the consumer with the **Payforit header box** and the **purchase button** contained on the page. At this stage, ImpulsePay have obtained the consumer's **MSISDN **to enable billing directly to that consumer's mobile bill. The consumer is then able to make a purchase, opt-in or out of further marketing using a tick box in the Payforit header, or exit the service without charge using the exit link contained in the Payforit header. The consumer can complete a purchase using the two step purchase button. Depending on the outcome of the purchase, the consumer will be either forwarded to the success URL or redirected to the failure URL, both of which the merchant provides on the Config page. [block:api-header] { "type": "basic", "title": "On a mobile wifi data connection" } [/block] On a Wifi data connection, the consumer experience differs only slightly to that of a mobile data connection, as follows: The consumer would gain access to the service using the **Service URL**. They would then be shown to the Merchant's payment page, which ImpulsePay host. This page is presented to the consumer with the **Payforit header box** and the **purchase button** contained on the page. As it is not possible to detect a MSISDN over a Wifi connection, when the consumer clicks the purchase button once, a prompt will appear within the button asking the consumer to click and call the automated verification number, which ImpulsePay provides. Once the consumer has made the 3 second call to the IVR system, ImpulsePay have verified the MSISDN and the billing attempt is made. Depending on the outcome of the purchase, the consumer will be either forwarded to the success URL or redirected to the failure URL, both of which the merchant provides. [block:api-header] { "type": "basic", "title": "On a desktop" } [/block] On a desktop, the user's consumer experience differs only slightly to that of a mobile data connection, as follows: The consumer would gain access to the service using the **Service URL**. They would then be shown to the payment page, which ImpulsePay host. This page is presented to the consumer with the **Payforit header box** and the **purchase button** contained on the page. As it is not possible to detect a MSISDN over a Wifi connection, when the consumer clicks the purchase button once, a prompt will appear within the button asking the consumer to insert their phone number and press 'Next'. The consumer will then receive a verification text message to their mobile from ImpulsePay asking them to click a link to confirm the purchase. The desktop payment page will then update depending on the outcome of the purchase. The consumer will be either forwarded to the success URL or redirected to the failure URL, both of which the merchant provides.
A single PaymentPage works seamlessly over both mobile data and wifi connections. The Dashboard allows merchants to easily customise their payment pages and configure services online. Merchants are able to configure multiple payment pages for a single service (to cater for different designs on desktop, iPhone, Android, iPad and generic mobile devices), upload their own HTML/CSS designs and also set up A/B testing to see which designs convert best on individual devices. [block:api-header] { "type": "basic", "title": "On a mobile data connection" } [/block] On a mobile data connection, a typical consumer experience would be as follows: The consumer would gain access to the service using the **Service URL**. They would then be shown to the Merchant's payment page, which ImpulsePay host. This page is presented to the consumer with the **Payforit header box** and the **purchase button** contained on the page. At this stage, ImpulsePay have obtained the consumer's **MSISDN **to enable billing directly to that consumer's mobile bill. The consumer is then able to make a purchase, opt-in or out of further marketing using a tick box in the Payforit header, or exit the service without charge using the exit link contained in the Payforit header. The consumer can complete a purchase using the two step purchase button. Depending on the outcome of the purchase, the consumer will be either forwarded to the success URL or redirected to the failure URL, both of which the merchant provides on the Config page. [block:api-header] { "type": "basic", "title": "On a mobile wifi data connection" } [/block] On a Wifi data connection, the consumer experience differs only slightly to that of a mobile data connection, as follows: The consumer would gain access to the service using the **Service URL**. They would then be shown to the Merchant's payment page, which ImpulsePay host. This page is presented to the consumer with the **Payforit header box** and the **purchase button** contained on the page. As it is not possible to detect a MSISDN over a Wifi connection, when the consumer clicks the purchase button once, a prompt will appear within the button asking the consumer to click and call the automated verification number, which ImpulsePay provides. Once the consumer has made the 3 second call to the IVR system, ImpulsePay have verified the MSISDN and the billing attempt is made. Depending on the outcome of the purchase, the consumer will be either forwarded to the success URL or redirected to the failure URL, both of which the merchant provides. [block:api-header] { "type": "basic", "title": "On a desktop" } [/block] On a desktop, the user's consumer experience differs only slightly to that of a mobile data connection, as follows: The consumer would gain access to the service using the **Service URL**. They would then be shown to the payment page, which ImpulsePay host. This page is presented to the consumer with the **Payforit header box** and the **purchase button** contained on the page. As it is not possible to detect a MSISDN over a Wifi connection, when the consumer clicks the purchase button once, a prompt will appear within the button asking the consumer to insert their phone number and press 'Next'. The consumer will then receive a verification text message to their mobile from ImpulsePay asking them to click a link to confirm the purchase. The desktop payment page will then update depending on the outcome of the purchase. The consumer will be either forwarded to the success URL or redirected to the failure URL, both of which the merchant provides.
{"__v":16,"_id":"5524f5bdd919032b0057ac42","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"There are a small number of prerequisites that need to be set up before Merchants can get started using PaymentPage.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"From the merchant\"\n}\n[/block]\nMost of this configuration is handled by the Dashboard Config page. \n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Requirement\",\n    \"h-1\": \"Usage\",\n    \"0-0\": \"Merchant's domain name\",\n    \"0-1\": \"To be used in the Service URL, this domain name should point to ImpulsePay's URL for the merchants payment page, using a CNAME record\",\n    \"1-0\": \"Setup of Payment template\",\n    \"2-0\": \"Payment failure URL\",\n    \"1-1\": \"The merchant must configure their payment page in the Editor and Configuration pages on the Dashboard\",\n    \"2-1\": \"This URL is where the consumer is redirected to, if the payment fails.\",\n    \"5-0\": \"Customer care helpline number\",\n    \"6-0\": \"Customer care email address\",\n    \"5-1\": \"This telephone number will be used by ImpulsePay to forward customer care enquiries to.\",\n    \"6-1\": \"This email address will be used by ImpulsePay to forward customer care enquiries received by email.\",\n    \"4-0\": \"Payment success URL\",\n    \"3-0\": \"Notification URL\",\n    \"3-1\": \"This URL is where billing notifications are sent by ImpulsePay to be processed by the merchant, if required by the merchant.\",\n    \"4-1\": \"This URL is where the consumer is redirected to, if the payment succeeds or if there is a free trial period in use.\",\n    \"7-0\": \"Terms and Conditions URL\",\n    \"7-1\": \"The Payforit header contains a link to merchant terms, using this URL hosted by the merchant.\"\n  },\n  \"cols\": 2,\n  \"rows\": 8\n}\n[/block]","category":"5524f5bcd919032b0057ac34","createdAt":"2015-02-23T14:43:07.651Z","excerpt":"An overview of what needs to be set up before getting connected","githubsync":"","hidden":false,"isReference":false,"link_external":false,"link_url":"","order":2,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"getting-connected","sync_unique":"","title":"Prerequisites","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Prerequisites

An overview of what needs to be set up before getting connected

There are a small number of prerequisites that need to be set up before Merchants can get started using PaymentPage. [block:api-header] { "type": "basic", "title": "From the merchant" } [/block] Most of this configuration is handled by the Dashboard Config page. [block:parameters] { "data": { "h-0": "Requirement", "h-1": "Usage", "0-0": "Merchant's domain name", "0-1": "To be used in the Service URL, this domain name should point to ImpulsePay's URL for the merchants payment page, using a CNAME record", "1-0": "Setup of Payment template", "2-0": "Payment failure URL", "1-1": "The merchant must configure their payment page in the Editor and Configuration pages on the Dashboard", "2-1": "This URL is where the consumer is redirected to, if the payment fails.", "5-0": "Customer care helpline number", "6-0": "Customer care email address", "5-1": "This telephone number will be used by ImpulsePay to forward customer care enquiries to.", "6-1": "This email address will be used by ImpulsePay to forward customer care enquiries received by email.", "4-0": "Payment success URL", "3-0": "Notification URL", "3-1": "This URL is where billing notifications are sent by ImpulsePay to be processed by the merchant, if required by the merchant.", "4-1": "This URL is where the consumer is redirected to, if the payment succeeds or if there is a free trial period in use.", "7-0": "Terms and Conditions URL", "7-1": "The Payforit header contains a link to merchant terms, using this URL hosted by the merchant." }, "cols": 2, "rows": 8 } [/block]
There are a small number of prerequisites that need to be set up before Merchants can get started using PaymentPage. [block:api-header] { "type": "basic", "title": "From the merchant" } [/block] Most of this configuration is handled by the Dashboard Config page. [block:parameters] { "data": { "h-0": "Requirement", "h-1": "Usage", "0-0": "Merchant's domain name", "0-1": "To be used in the Service URL, this domain name should point to ImpulsePay's URL for the merchants payment page, using a CNAME record", "1-0": "Setup of Payment template", "2-0": "Payment failure URL", "1-1": "The merchant must configure their payment page in the Editor and Configuration pages on the Dashboard", "2-1": "This URL is where the consumer is redirected to, if the payment fails.", "5-0": "Customer care helpline number", "6-0": "Customer care email address", "5-1": "This telephone number will be used by ImpulsePay to forward customer care enquiries to.", "6-1": "This email address will be used by ImpulsePay to forward customer care enquiries received by email.", "4-0": "Payment success URL", "3-0": "Notification URL", "3-1": "This URL is where billing notifications are sent by ImpulsePay to be processed by the merchant, if required by the merchant.", "4-1": "This URL is where the consumer is redirected to, if the payment succeeds or if there is a free trial period in use.", "7-0": "Terms and Conditions URL", "7-1": "The Payforit header contains a link to merchant terms, using this URL hosted by the merchant." }, "cols": 2, "rows": 8 } [/block]
{"__v":14,"_id":"564b0d6890f4230d0080c8c0","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"Merchants should be aware of the following key Payforit scheme rules, which as a wider part of the Payforit Scheme, govern the ImpulsePay flow including the Payforit Header box, the purchase button and the charge notification area. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Payforit Header Box\"\n}\n[/block]\nThe header box is displayed to ensure key information such as consumer terms and helpline is displayed appropriately to consumers. This area also contains the logos of the 4 primary MNOs (O2, EE, Three and Vodafone) which helps raise awareness that this service will charge a consumers mobile phone bill.\n\nThe following is a subset of some of the Payforit scheme rules that apply to this part:\n\n**1.2.2** Header Box Rules\n\n**1.2.2.1** The header box is mandated and supplied by the Payforit Management Group and must be static (floating) at the top of the screen. \n\n**1.2.2.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.\n\n**1.2.2.3 **No other form of header box using a similar style is permitted on the promotional pages.\n \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Confirmation Page\"\n}\n[/block]\nEach Payment page must have a payment received screen shown immediately after the payment page. ImpulsePay hosts this page on behalf of the merchant and it can be created on the dashboard in a similar way to normal payment pages. See [Confirmation page](doc:confirmation-page) for more details.  \n\n1.1.1.7 The API (ImpulsePay) must serve a payment received screen (or subscription activated screen) and send text receipt message once a charge has been made. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Purchase Button\"\n}\n[/block]\nThe Purchase button is a button that the consumer clicks to confirm their consent to be charged. Whilst the colours are variable, the size and style is stipulated in the Payforit scheme rules. Once the first button is clicked, the consumer will be presented with a second button or options to verify their MSISDN depending on the connection type.\n\n\nThe following is a subset of some of the Payforit scheme rules that apply to this part:\n**1.2.5 Call to Action Buttons**\n\n**1.2.5.1** Across a two step payment process, the two buttons must be a different colour to each other with a minimum contrast ratio of 2:1\n\n**1.2.5.2** Call to Action buttons may be presented in a different colour providing that the contrast between text and button colour is contrasting as follows;\n\n**1.2.5.2.1** Convert the dominant background colour to HSL (hue, saturation, lightness). \n**1.2.5.2.2** Present the text in white (#FFFFF) when the lightness is less than 50%.  \n**1.2.5.2.3** Present the text in black (#00000) when the lightness is greater than 50%.\n\n**1.2.5.2.4** Present the text in either white or black when the lightness is exactly 50%.\n\n**1.2.5.3** Buttons must be horizontal with the button text also horizontally presented central to both horizontal and vertical axis. \n\n**1.2.5.4 **Button 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 buttons. \n\n**1.2.5.5 **Both buttons have a padding of 10px around all edges, border radius of 7 to 11 px, central aligned text and no CSS text decoration.\n\n**1.2.5.6** Both buttons have a vertical padding of 20px and horizontal padding of 10px. Both buttons will only contain text without any logos, images or icons.\n\n**1.2.5.7** Both buttons colour has a minimum Contrast Ratio of 4:1 to the background colour that surrounds the button. Background colours must be solid with no gradients, patterns or shadows permitted.\n\n**1.2.5.8 **Buttons can be graduated with a top to bottom darkening of colour with the contrast ratio between top and bottom colours no greater than 2:1. \n\n**1.2.5.9** Buttons can have rounded corners between 7 to 11 pixels. \n\n**1.2.5.10** Buttons can have a border that is either the same as the darkest part of the button or black (#000000) or white (#ffffff). \n\n**1.2.5.11** Button text must be 12px to 14px, black (#000000) or white (#ffffff)\n\n**1.2.5.12** All text on the buttons is of the same font, colour and size and must be the same font, style and size as the Charge Notification text. Title casing or sentence casing is permitted.\n\n**1.2.5.13 **Contrast Ratio is determined by WCAG 2.0 guidelines and tested using typical on line tools. \n\n**1.2.5.14** A maximum of 8px gap and minimum 2px gap between the end of the Charge Notification text and the top of the both buttons must exist. \n\n**1.2.5.15** The price must appear on the first call to action button and follow these rules:\n**1.2.5.15.1** One-off payment: Buy Now for <Price> \n**1.2.5.15.2** One-off charity donation: Donate <price> now\n**1.2.5.15.3** Standard subscription: Subscribe Now for <price> [per/every/a] <billing frequency>\n**1.2.5.15.4** Subscription with free trial: Subscribe Now for <price> [per/every/a] <billing frequency> after <period> free\n**1.2.5.15.5** Subscription with differing initial charge: Subscribe Now for <initial charge> then <price> [per/every/a] <billing frequency> \n**1.2.5.15.6** Charity subscription: Donate <price> [per/every/a] <billing frequency> \n\n**1.2.5.16** When the MSISDN is confirmed the charging confirmation must appear on the second payment button: “Confirm this charge to your mobile\"\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Charge Notification Area\"\n}\n[/block]\nThe charge notification area is the part of the screen immediately surrounding the purchase button. The area outside of this can be controlled by the merchant, however the style of the charge notification is governed by the Payforit scheme rules.\n\nThe following is a subset of some of the Payforit scheme rules that apply to this part:\n**1.2.4** Charge Notification Field\n\n**1.2.4.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.\n\n**1.2.4.2 **Charge notification must be white text on black background or black text on white background and must be the same font, style and size as the text on the call to action button.","category":"5524f5bcd919032b0057ac34","createdAt":"2015-11-17T11:20:08.927Z","excerpt":"A introduction of the key scheme rules","githubsync":"","hidden":false,"isReference":false,"link_external":false,"link_url":"","order":3,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"payforit-scheme-rules","sync_unique":"","title":"Payforit Scheme Rules","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Payforit Scheme Rules

A introduction of the key scheme rules

Merchants should be aware of the following key Payforit scheme rules, which as a wider part of the Payforit Scheme, govern the ImpulsePay flow including the Payforit Header box, the purchase button and the charge notification area. [block:api-header] { "type": "basic", "title": "Payforit Header Box" } [/block] The header box is displayed to ensure key information such as consumer terms and helpline is displayed appropriately to consumers. This area also contains the logos of the 4 primary MNOs (O2, EE, Three and Vodafone) which helps raise awareness that this service will charge a consumers mobile phone bill. The following is a subset of some of the Payforit scheme rules that apply to this part: **1.2.2** Header Box Rules **1.2.2.1** The header box is mandated and supplied by the Payforit Management Group and must be static (floating) at the top of the screen. **1.2.2.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.2.3 **No other form of header box using a similar style is permitted on the promotional pages. [block:api-header] { "type": "basic", "title": "Confirmation Page" } [/block] Each Payment page must have a payment received screen shown immediately after the payment page. ImpulsePay hosts this page on behalf of the merchant and it can be created on the dashboard in a similar way to normal payment pages. See [Confirmation page](doc:confirmation-page) for more details. 1.1.1.7 The API (ImpulsePay) must serve a payment received screen (or subscription activated screen) and send text receipt message once a charge has been made. [block:api-header] { "type": "basic", "title": "Purchase Button" } [/block] The Purchase button is a button that the consumer clicks to confirm their consent to be charged. Whilst the colours are variable, the size and style is stipulated in the Payforit scheme rules. Once the first button is clicked, the consumer will be presented with a second button or options to verify their MSISDN depending on the connection type. The following is a subset of some of the Payforit scheme rules that apply to this part: **1.2.5 Call to Action Buttons** **1.2.5.1** Across a two step payment process, the two buttons must be a different colour to each other with a minimum contrast ratio of 2:1 **1.2.5.2** 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.5.2.1** Convert the dominant background colour to HSL (hue, saturation, lightness). **1.2.5.2.2** Present the text in white (#FFFFF) when the lightness is less than 50%. **1.2.5.2.3** Present the text in black (#00000) when the lightness is greater than 50%. **1.2.5.2.4** Present the text in either white or black when the lightness is exactly 50%. **1.2.5.3** Buttons must be horizontal with the button text also horizontally presented central to both horizontal and vertical axis. **1.2.5.4 **Button 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 buttons. **1.2.5.5 **Both buttons have a padding of 10px around all edges, border radius of 7 to 11 px, central aligned text and no CSS text decoration. **1.2.5.6** Both buttons have a vertical padding of 20px and horizontal padding of 10px. Both buttons will only contain text without any logos, images or icons. **1.2.5.7** Both buttons colour has a minimum Contrast Ratio of 4:1 to the background colour that surrounds the button. Background colours must be solid with no gradients, patterns or shadows permitted. **1.2.5.8 **Buttons can be graduated with a top to bottom darkening of colour with the contrast ratio between top and bottom colours no greater than 2:1. **1.2.5.9** Buttons can have rounded corners between 7 to 11 pixels. **1.2.5.10** Buttons can have a border that is either the same as the darkest part of the button or black (#000000) or white (#ffffff). **1.2.5.11** Button text must be 12px to 14px, black (#000000) or white (#ffffff) **1.2.5.12** All text on the buttons is of the same font, colour and size and must be the same font, style and size as the Charge Notification text. Title casing or sentence casing is permitted. **1.2.5.13 **Contrast Ratio is determined by WCAG 2.0 guidelines and tested using typical on line tools. **1.2.5.14** A maximum of 8px gap and minimum 2px gap between the end of the Charge Notification text and the top of the both buttons must exist. **1.2.5.15** The price must appear on the first call to action button and follow these rules: **1.2.5.15.1** One-off payment: Buy Now for <Price> **1.2.5.15.2** One-off charity donation: Donate <price> now **1.2.5.15.3** Standard subscription: Subscribe Now for <price> [per/every/a] <billing frequency> **1.2.5.15.4** Subscription with free trial: Subscribe Now for <price> [per/every/a] <billing frequency> after <period> free **1.2.5.15.5** Subscription with differing initial charge: Subscribe Now for <initial charge> then <price> [per/every/a] <billing frequency> **1.2.5.15.6** Charity subscription: Donate <price> [per/every/a] <billing frequency> **1.2.5.16** When the MSISDN is confirmed the charging confirmation must appear on the second payment button: “Confirm this charge to your mobile" [block:api-header] { "type": "basic", "title": "Charge Notification Area" } [/block] The charge notification area is the part of the screen immediately surrounding the purchase button. The area outside of this can be controlled by the merchant, however the style of the charge notification is governed by the Payforit scheme rules. The following is a subset of some of the Payforit scheme rules that apply to this part: **1.2.4** Charge Notification Field **1.2.4.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.4.2 **Charge notification must be white text on black background or black text on white background and must be the same font, style and size as the text on the call to action button.
Merchants should be aware of the following key Payforit scheme rules, which as a wider part of the Payforit Scheme, govern the ImpulsePay flow including the Payforit Header box, the purchase button and the charge notification area. [block:api-header] { "type": "basic", "title": "Payforit Header Box" } [/block] The header box is displayed to ensure key information such as consumer terms and helpline is displayed appropriately to consumers. This area also contains the logos of the 4 primary MNOs (O2, EE, Three and Vodafone) which helps raise awareness that this service will charge a consumers mobile phone bill. The following is a subset of some of the Payforit scheme rules that apply to this part: **1.2.2** Header Box Rules **1.2.2.1** The header box is mandated and supplied by the Payforit Management Group and must be static (floating) at the top of the screen. **1.2.2.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.2.3 **No other form of header box using a similar style is permitted on the promotional pages. [block:api-header] { "type": "basic", "title": "Confirmation Page" } [/block] Each Payment page must have a payment received screen shown immediately after the payment page. ImpulsePay hosts this page on behalf of the merchant and it can be created on the dashboard in a similar way to normal payment pages. See [Confirmation page](doc:confirmation-page) for more details. 1.1.1.7 The API (ImpulsePay) must serve a payment received screen (or subscription activated screen) and send text receipt message once a charge has been made. [block:api-header] { "type": "basic", "title": "Purchase Button" } [/block] The Purchase button is a button that the consumer clicks to confirm their consent to be charged. Whilst the colours are variable, the size and style is stipulated in the Payforit scheme rules. Once the first button is clicked, the consumer will be presented with a second button or options to verify their MSISDN depending on the connection type. The following is a subset of some of the Payforit scheme rules that apply to this part: **1.2.5 Call to Action Buttons** **1.2.5.1** Across a two step payment process, the two buttons must be a different colour to each other with a minimum contrast ratio of 2:1 **1.2.5.2** 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.5.2.1** Convert the dominant background colour to HSL (hue, saturation, lightness). **1.2.5.2.2** Present the text in white (#FFFFF) when the lightness is less than 50%. **1.2.5.2.3** Present the text in black (#00000) when the lightness is greater than 50%. **1.2.5.2.4** Present the text in either white or black when the lightness is exactly 50%. **1.2.5.3** Buttons must be horizontal with the button text also horizontally presented central to both horizontal and vertical axis. **1.2.5.4 **Button 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 buttons. **1.2.5.5 **Both buttons have a padding of 10px around all edges, border radius of 7 to 11 px, central aligned text and no CSS text decoration. **1.2.5.6** Both buttons have a vertical padding of 20px and horizontal padding of 10px. Both buttons will only contain text without any logos, images or icons. **1.2.5.7** Both buttons colour has a minimum Contrast Ratio of 4:1 to the background colour that surrounds the button. Background colours must be solid with no gradients, patterns or shadows permitted. **1.2.5.8 **Buttons can be graduated with a top to bottom darkening of colour with the contrast ratio between top and bottom colours no greater than 2:1. **1.2.5.9** Buttons can have rounded corners between 7 to 11 pixels. **1.2.5.10** Buttons can have a border that is either the same as the darkest part of the button or black (#000000) or white (#ffffff). **1.2.5.11** Button text must be 12px to 14px, black (#000000) or white (#ffffff) **1.2.5.12** All text on the buttons is of the same font, colour and size and must be the same font, style and size as the Charge Notification text. Title casing or sentence casing is permitted. **1.2.5.13 **Contrast Ratio is determined by WCAG 2.0 guidelines and tested using typical on line tools. **1.2.5.14** A maximum of 8px gap and minimum 2px gap between the end of the Charge Notification text and the top of the both buttons must exist. **1.2.5.15** The price must appear on the first call to action button and follow these rules: **1.2.5.15.1** One-off payment: Buy Now for <Price> **1.2.5.15.2** One-off charity donation: Donate <price> now **1.2.5.15.3** Standard subscription: Subscribe Now for <price> [per/every/a] <billing frequency> **1.2.5.15.4** Subscription with free trial: Subscribe Now for <price> [per/every/a] <billing frequency> after <period> free **1.2.5.15.5** Subscription with differing initial charge: Subscribe Now for <initial charge> then <price> [per/every/a] <billing frequency> **1.2.5.15.6** Charity subscription: Donate <price> [per/every/a] <billing frequency> **1.2.5.16** When the MSISDN is confirmed the charging confirmation must appear on the second payment button: “Confirm this charge to your mobile" [block:api-header] { "type": "basic", "title": "Charge Notification Area" } [/block] The charge notification area is the part of the screen immediately surrounding the purchase button. The area outside of this can be controlled by the merchant, however the style of the charge notification is governed by the Payforit scheme rules. The following is a subset of some of the Payforit scheme rules that apply to this part: **1.2.4** Charge Notification Field **1.2.4.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.4.2 **Charge notification must be white text on black background or black text on white background and must be the same font, style and size as the text on the call to action button.
{"__v":14,"_id":"5524f5bdd919032b0057ac51","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"The Payforit header box is a mandatory part of the Payforit scheme; a wider set of user experience rules and guidelines for the PaymentPages. The header box is automatically added to a merchant's payment page by ImpulsePay, when the page is loaded by the consumer. \n\nThe header box will float at the top of page if user scrolls down the page to ensure it remains visible at all times.\n\nThe header box contains a merchant's helpline number, terms and conditions links and an exit page link to allow the consumer to leave the page without making a purchase.\n\n\n\n\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/p5nCzi0FTX8SPu2Irmes_Screen%20Shot%202015-11-17%20at%2012.25.13.png\",\n        \"Screen Shot 2015-11-17 at 12.25.13.png\",\n        \"1306\",\n        \"170\",\n        \"#ec1c2c\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]","category":"5524f5bcd919032b0057ac35","createdAt":"2015-02-23T14:55:42.991Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":0,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"payforit-header-box","sync_unique":"","title":"Payforit Header Box","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Payforit Header Box


The Payforit header box is a mandatory part of the Payforit scheme; a wider set of user experience rules and guidelines for the PaymentPages. The header box is automatically added to a merchant's payment page by ImpulsePay, when the page is loaded by the consumer. The header box will float at the top of page if user scrolls down the page to ensure it remains visible at all times. The header box contains a merchant's helpline number, terms and conditions links and an exit page link to allow the consumer to leave the page without making a purchase. [block:image] { "images": [ { "image": [ "https://files.readme.io/p5nCzi0FTX8SPu2Irmes_Screen%20Shot%202015-11-17%20at%2012.25.13.png", "Screen Shot 2015-11-17 at 12.25.13.png", "1306", "170", "#ec1c2c", "" ] } ] } [/block]
The Payforit header box is a mandatory part of the Payforit scheme; a wider set of user experience rules and guidelines for the PaymentPages. The header box is automatically added to a merchant's payment page by ImpulsePay, when the page is loaded by the consumer. The header box will float at the top of page if user scrolls down the page to ensure it remains visible at all times. The header box contains a merchant's helpline number, terms and conditions links and an exit page link to allow the consumer to leave the page without making a purchase. [block:image] { "images": [ { "image": [ "https://files.readme.io/p5nCzi0FTX8SPu2Irmes_Screen%20Shot%202015-11-17%20at%2012.25.13.png", "Screen Shot 2015-11-17 at 12.25.13.png", "1306", "170", "#ec1c2c", "" ] } ] } [/block]
{"__v":11,"_id":"560e597a59cb8d0d0015ccd4","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"A purchase is initiated by a consumer by using the purchase button. The purchase button is a two-step process, similar to the experience on app stores. Merchants may have more than one purchase button on their payment page.\n\nThe purchase button area consists of a purchase button and a charge notification statement which are dynamically loaded into the payment page by ImpulsePay.\n\nMerchants have control over the button colour and gradient (subject to visibility requirements) and can add text before and after the charge notification statement if they wish. \n\nIn the two-step process, the initial button wording will always be the same regardless of which MSISDN verification method is being used, as follows: \n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/KeRCyItkRQGui1dOv9gh_initial.PNG\",\n        \"initial.PNG\",\n        \"384\",\n        \"106\",\n        \"#135940\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nFollowing the initial click, the second button will show as follows on 3G verification, with the charge notification statement updated to include pricing information: \n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/766czmiTzyaJtxvwGGDV_second.PNG\",\n        \"second.PNG\",\n        \"369\",\n        \"109\",\n        \"#3eac1e\",\n        \"\"\n      ],\n      \"caption\": \"\"\n    }\n  ]\n}\n[/block]\nThe second button will show on IVR verification (Mobile wifi) as follows: \n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/J5WnQJfRdWKtULtcYEHk_Screen%20Shot%202015-10-05%20at%2015.42.43.png\",\n        \"Screen Shot 2015-10-05 at 15.42.43.png\",\n        \"300\",\n        \"106\",\n        \"#4c8b43\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nThe second button will show on MO verification (desktop) as follows:\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/LHouSPieQPyiobURQH3x_Screen%20Shot%202015-10-05%20at%2015.22.16.png\",\n        \"Screen Shot 2015-10-05 at 15.22.16.png\",\n        \"449\",\n        \"111\",\n        \"#4c8c44\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nThe second button will show on MT verification (desktop) as follows:\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/bzBPsjhvSjG5aAxWnYA0_Screen%20Shot%202015-10-05%20at%2015.24.39.png\",\n        \"Screen Shot 2015-10-05 at 15.24.39.png\",\n        \"421\",\n        \"111\",\n        \"#4c8c44\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Charge Notification Area\"\n}\n[/block]\nThe charge notification area is the text above the purchase button. Merchants are able to wrap text either side of this notification text, see [Advanced Features](doc:first-click-events)  for more details.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Rules on button colours and gradient\"\n}\n[/block]\nWhen configuring the purchase buttons, it is important to note the following rules:\n\n- The button colour for both first and second buttons must exceed a 5:1 contrast of the charge notification area colour.\n- The charge notification area must be white and the charge notification text must be black. \n- The button colour of the first and second purchase buttons must exceed a contrast ratio of 2:1. \n\nPlease see [Header and Button Config](doc:purchase-button-area-configuration) section for more detail on configuring Purchase Buttons and charge notification area.","category":"5524f5bcd919032b0057ac35","createdAt":"2015-10-02T10:16:26.482Z","excerpt":"Information on the purchase button and charge notification area","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":1,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"purchase-button-area","sync_unique":"","title":"Purchase Button Area","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Purchase Button Area

Information on the purchase button and charge notification area

A purchase is initiated by a consumer by using the purchase button. The purchase button is a two-step process, similar to the experience on app stores. Merchants may have more than one purchase button on their payment page. The purchase button area consists of a purchase button and a charge notification statement which are dynamically loaded into the payment page by ImpulsePay. Merchants have control over the button colour and gradient (subject to visibility requirements) and can add text before and after the charge notification statement if they wish. In the two-step process, the initial button wording will always be the same regardless of which MSISDN verification method is being used, as follows: [block:image] { "images": [ { "image": [ "https://files.readme.io/KeRCyItkRQGui1dOv9gh_initial.PNG", "initial.PNG", "384", "106", "#135940", "" ] } ] } [/block] Following the initial click, the second button will show as follows on 3G verification, with the charge notification statement updated to include pricing information: [block:image] { "images": [ { "image": [ "https://files.readme.io/766czmiTzyaJtxvwGGDV_second.PNG", "second.PNG", "369", "109", "#3eac1e", "" ], "caption": "" } ] } [/block] The second button will show on IVR verification (Mobile wifi) as follows: [block:image] { "images": [ { "image": [ "https://files.readme.io/J5WnQJfRdWKtULtcYEHk_Screen%20Shot%202015-10-05%20at%2015.42.43.png", "Screen Shot 2015-10-05 at 15.42.43.png", "300", "106", "#4c8b43", "" ] } ] } [/block] The second button will show on MO verification (desktop) as follows: [block:image] { "images": [ { "image": [ "https://files.readme.io/LHouSPieQPyiobURQH3x_Screen%20Shot%202015-10-05%20at%2015.22.16.png", "Screen Shot 2015-10-05 at 15.22.16.png", "449", "111", "#4c8c44", "" ] } ] } [/block] The second button will show on MT verification (desktop) as follows: [block:image] { "images": [ { "image": [ "https://files.readme.io/bzBPsjhvSjG5aAxWnYA0_Screen%20Shot%202015-10-05%20at%2015.24.39.png", "Screen Shot 2015-10-05 at 15.24.39.png", "421", "111", "#4c8c44", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Charge Notification Area" } [/block] The charge notification area is the text above the purchase button. Merchants are able to wrap text either side of this notification text, see [Advanced Features](doc:first-click-events) for more details. [block:api-header] { "type": "basic", "title": "Rules on button colours and gradient" } [/block] When configuring the purchase buttons, it is important to note the following rules: - The button colour for both first and second buttons must exceed a 5:1 contrast of the charge notification area colour. - The charge notification area must be white and the charge notification text must be black. - The button colour of the first and second purchase buttons must exceed a contrast ratio of 2:1. Please see [Header and Button Config](doc:purchase-button-area-configuration) section for more detail on configuring Purchase Buttons and charge notification area.
A purchase is initiated by a consumer by using the purchase button. The purchase button is a two-step process, similar to the experience on app stores. Merchants may have more than one purchase button on their payment page. The purchase button area consists of a purchase button and a charge notification statement which are dynamically loaded into the payment page by ImpulsePay. Merchants have control over the button colour and gradient (subject to visibility requirements) and can add text before and after the charge notification statement if they wish. In the two-step process, the initial button wording will always be the same regardless of which MSISDN verification method is being used, as follows: [block:image] { "images": [ { "image": [ "https://files.readme.io/KeRCyItkRQGui1dOv9gh_initial.PNG", "initial.PNG", "384", "106", "#135940", "" ] } ] } [/block] Following the initial click, the second button will show as follows on 3G verification, with the charge notification statement updated to include pricing information: [block:image] { "images": [ { "image": [ "https://files.readme.io/766czmiTzyaJtxvwGGDV_second.PNG", "second.PNG", "369", "109", "#3eac1e", "" ], "caption": "" } ] } [/block] The second button will show on IVR verification (Mobile wifi) as follows: [block:image] { "images": [ { "image": [ "https://files.readme.io/J5WnQJfRdWKtULtcYEHk_Screen%20Shot%202015-10-05%20at%2015.42.43.png", "Screen Shot 2015-10-05 at 15.42.43.png", "300", "106", "#4c8b43", "" ] } ] } [/block] The second button will show on MO verification (desktop) as follows: [block:image] { "images": [ { "image": [ "https://files.readme.io/LHouSPieQPyiobURQH3x_Screen%20Shot%202015-10-05%20at%2015.22.16.png", "Screen Shot 2015-10-05 at 15.22.16.png", "449", "111", "#4c8c44", "" ] } ] } [/block] The second button will show on MT verification (desktop) as follows: [block:image] { "images": [ { "image": [ "https://files.readme.io/bzBPsjhvSjG5aAxWnYA0_Screen%20Shot%202015-10-05%20at%2015.24.39.png", "Screen Shot 2015-10-05 at 15.24.39.png", "421", "111", "#4c8c44", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Charge Notification Area" } [/block] The charge notification area is the text above the purchase button. Merchants are able to wrap text either side of this notification text, see [Advanced Features](doc:first-click-events) for more details. [block:api-header] { "type": "basic", "title": "Rules on button colours and gradient" } [/block] When configuring the purchase buttons, it is important to note the following rules: - The button colour for both first and second buttons must exceed a 5:1 contrast of the charge notification area colour. - The charge notification area must be white and the charge notification text must be black. - The button colour of the first and second purchase buttons must exceed a contrast ratio of 2:1. Please see [Header and Button Config](doc:purchase-button-area-configuration) section for more detail on configuring Purchase Buttons and charge notification area.
{"__v":14,"_id":"5524f5bdd919032b0057ac56","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"With recurring payments (RPs), it is possible for consumers to establish regular payments whereby they will be charged on a merchant-defined frequency (a maximum of 1 bill per week) over a merchant-defined billing period. \n\nAccess to a service is monitored by the AccountID and FriendlyName parameters, therefore a FriendlyName can be shared across different RouteIDs (Services) to ensure that either a single or recurring payment applies to all services, or in the case of different FriendlyName values, does not apply to others.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Free trials, initial charge and variable tariffs\"\n}\n[/block]\nIt is also possible for merchants to run a free trial with a minimum 1 hour free period. The initial charge will be £0 and after the free period has elapsed, the recurring tariff specified by the merchant will be charged over the defined period. \n\nMerchants can also setup recurring payments whereby the consumer is charged an initial tariff, then charged a different tariff for all subsequent recurring payments. See [Button Parameters](doc:purchase-button-area-configuration) for more information on setting up Recurring Payments. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"120 Day inactivity rule\"\n}\n[/block]\nIf a consumer has been opted-in to a recurring payment cycle for more than 120 days and has not interacted with the service for which access has been paid, then they will be automatically opted-out by ImpulsePay and will not be billed again for that service until they have opted back in. \n\nThe consumer and merchant will not be sent a notification of this automatic opt-out process.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Detecting consumer interaction\"\n}\n[/block]\nEach time the consumer uses the service after they have joined, their activity can be logged and the '120 day inactivity' period is reset to the current date. Either of the following options can be used to log this activity:\n\n**Website login**\n\nThe merchant's website should have a secure login area. Once the consumer has logged in, the activity detection may take place by using an ImpulsePay tracking pixel on the page after the consumer login. \n\n**Text message** \n\nThe consumer is sent a text message which identifies the service. They can then click a link to access the merchant's site.\n\n**Re-attempt to purchase**\n\nIf the consumer attempts to purchase the access again, whilst already within a recurring billing cycle then their start date is reset to the current date. In this scenario they are not charged again and a 170 status code is passed to the success URL.","category":"5524f5bcd919032b0057ac35","createdAt":"2015-02-24T19:15:20.798Z","excerpt":"Information and rules when using recurring payments (RPs)","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":3,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"recurring-payments","sync_unique":"","title":"Using Recurring Payments","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Using Recurring Payments

Information and rules when using recurring payments (RPs)

With recurring payments (RPs), it is possible for consumers to establish regular payments whereby they will be charged on a merchant-defined frequency (a maximum of 1 bill per week) over a merchant-defined billing period. Access to a service is monitored by the AccountID and FriendlyName parameters, therefore a FriendlyName can be shared across different RouteIDs (Services) to ensure that either a single or recurring payment applies to all services, or in the case of different FriendlyName values, does not apply to others. [block:api-header] { "type": "basic", "title": "Free trials, initial charge and variable tariffs" } [/block] It is also possible for merchants to run a free trial with a minimum 1 hour free period. The initial charge will be £0 and after the free period has elapsed, the recurring tariff specified by the merchant will be charged over the defined period. Merchants can also setup recurring payments whereby the consumer is charged an initial tariff, then charged a different tariff for all subsequent recurring payments. See [Button Parameters](doc:purchase-button-area-configuration) for more information on setting up Recurring Payments. [block:api-header] { "type": "basic", "title": "120 Day inactivity rule" } [/block] If a consumer has been opted-in to a recurring payment cycle for more than 120 days and has not interacted with the service for which access has been paid, then they will be automatically opted-out by ImpulsePay and will not be billed again for that service until they have opted back in. The consumer and merchant will not be sent a notification of this automatic opt-out process. [block:api-header] { "type": "basic", "title": "Detecting consumer interaction" } [/block] Each time the consumer uses the service after they have joined, their activity can be logged and the '120 day inactivity' period is reset to the current date. Either of the following options can be used to log this activity: **Website login** The merchant's website should have a secure login area. Once the consumer has logged in, the activity detection may take place by using an ImpulsePay tracking pixel on the page after the consumer login. **Text message** The consumer is sent a text message which identifies the service. They can then click a link to access the merchant's site. **Re-attempt to purchase** If the consumer attempts to purchase the access again, whilst already within a recurring billing cycle then their start date is reset to the current date. In this scenario they are not charged again and a 170 status code is passed to the success URL.
With recurring payments (RPs), it is possible for consumers to establish regular payments whereby they will be charged on a merchant-defined frequency (a maximum of 1 bill per week) over a merchant-defined billing period. Access to a service is monitored by the AccountID and FriendlyName parameters, therefore a FriendlyName can be shared across different RouteIDs (Services) to ensure that either a single or recurring payment applies to all services, or in the case of different FriendlyName values, does not apply to others. [block:api-header] { "type": "basic", "title": "Free trials, initial charge and variable tariffs" } [/block] It is also possible for merchants to run a free trial with a minimum 1 hour free period. The initial charge will be £0 and after the free period has elapsed, the recurring tariff specified by the merchant will be charged over the defined period. Merchants can also setup recurring payments whereby the consumer is charged an initial tariff, then charged a different tariff for all subsequent recurring payments. See [Button Parameters](doc:purchase-button-area-configuration) for more information on setting up Recurring Payments. [block:api-header] { "type": "basic", "title": "120 Day inactivity rule" } [/block] If a consumer has been opted-in to a recurring payment cycle for more than 120 days and has not interacted with the service for which access has been paid, then they will be automatically opted-out by ImpulsePay and will not be billed again for that service until they have opted back in. The consumer and merchant will not be sent a notification of this automatic opt-out process. [block:api-header] { "type": "basic", "title": "Detecting consumer interaction" } [/block] Each time the consumer uses the service after they have joined, their activity can be logged and the '120 day inactivity' period is reset to the current date. Either of the following options can be used to log this activity: **Website login** The merchant's website should have a secure login area. Once the consumer has logged in, the activity detection may take place by using an ImpulsePay tracking pixel on the page after the consumer login. **Text message** The consumer is sent a text message which identifies the service. They can then click a link to access the merchant's site. **Re-attempt to purchase** If the consumer attempts to purchase the access again, whilst already within a recurring billing cycle then their start date is reset to the current date. In this scenario they are not charged again and a 170 status code is passed to the success URL.
{"__v":5,"_id":"5524f5bdd919032b0057ac3e","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"Billing retries are not allowed at the point of purchase. However, for recurring payments a limited retry strategy may be used for payments that utilise a free trial period or additional payments attempted after the first one, when access to the MNO billing systems is not available.\n\nWhen used, there is an exponential back-off policy up to 8 days (14 attempts). This means that a payment is attempted at increasing intervals to the previous until the 14th attempt has been made. \n\nAttempts are made at:\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Attempt number\",\n    \"h-1\": \"Time in minutes\",\n    \"0-0\": \"1\",\n    \"1-0\": \"2\",\n    \"2-0\": \"3\",\n    \"3-0\": \"4\",\n    \"4-0\": \"5\",\n    \"5-0\": \"6\",\n    \"6-0\": \"7\",\n    \"7-0\": \"8\",\n    \"8-0\": \"9\",\n    \"9-0\": \"10\",\n    \"10-0\": \"11\",\n    \"11-0\": \"12\",\n    \"12-0\": \"13\",\n    \"13-0\": \"14\",\n    \"0-1\": \"2\",\n    \"1-1\": \"4\",\n    \"2-1\": \"8\",\n    \"3-1\": \"16\",\n    \"4-1\": \"32\",\n    \"5-1\": \"64\",\n    \"6-1\": \"128\",\n    \"7-1\": \"256\",\n    \"8-1\": \"512\",\n    \"9-1\": \"1024\",\n    \"10-1\": \"2048\",\n    \"11-1\": \"4096\",\n    \"12-1\": \"8192\",\n    \"13-1\": \"16384\"\n  },\n  \"cols\": 2,\n  \"rows\": 14\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Recurring Payment retry policy\"\n}\n[/block]\nRecurring Payment transactions are made on the anniversary of the previous charge. For example, a recurring payment with a frequency of 1 week made at 10am on the 1st of April will next be billed at 10am on the 7th April. \n\nOn the anniversary of a recurring payment, if the transaction fails for any reason and a retry period has not been set up, paid access will expire and the merchant will be sent a notification. Otherwise, a transaction will fail and then be retried using an exponential back off approach. If the transaction reaches the end of the retry policy and has still not billed successfully, a transaction failed status will be sent to the merchant. \n\nIf the transaction is successful during the retry policy, access is granted from the date and time the transaction is successfully made. For example, on a 1 week recurring payment frequency, which fails initially at 10am on the 1st April, but successfully bills at 15:30 on 1st April will next be billed at 15:30 on the 7th April. \n\nDuring the period of retrying a failed transaction, the consumer will not be granted access to the service until a successful transaction is made.","category":"5524f5bcd919032b0057ac35","createdAt":"2015-02-23T15:08:03.858Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":4,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"billing-retry-policies","sync_unique":"","title":"Billing Retry Policy","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Billing Retry Policy


Billing retries are not allowed at the point of purchase. However, for recurring payments a limited retry strategy may be used for payments that utilise a free trial period or additional payments attempted after the first one, when access to the MNO billing systems is not available. When used, there is an exponential back-off policy up to 8 days (14 attempts). This means that a payment is attempted at increasing intervals to the previous until the 14th attempt has been made. Attempts are made at: [block:parameters] { "data": { "h-0": "Attempt number", "h-1": "Time in minutes", "0-0": "1", "1-0": "2", "2-0": "3", "3-0": "4", "4-0": "5", "5-0": "6", "6-0": "7", "7-0": "8", "8-0": "9", "9-0": "10", "10-0": "11", "11-0": "12", "12-0": "13", "13-0": "14", "0-1": "2", "1-1": "4", "2-1": "8", "3-1": "16", "4-1": "32", "5-1": "64", "6-1": "128", "7-1": "256", "8-1": "512", "9-1": "1024", "10-1": "2048", "11-1": "4096", "12-1": "8192", "13-1": "16384" }, "cols": 2, "rows": 14 } [/block] [block:api-header] { "type": "basic", "title": "Recurring Payment retry policy" } [/block] Recurring Payment transactions are made on the anniversary of the previous charge. For example, a recurring payment with a frequency of 1 week made at 10am on the 1st of April will next be billed at 10am on the 7th April. On the anniversary of a recurring payment, if the transaction fails for any reason and a retry period has not been set up, paid access will expire and the merchant will be sent a notification. Otherwise, a transaction will fail and then be retried using an exponential back off approach. If the transaction reaches the end of the retry policy and has still not billed successfully, a transaction failed status will be sent to the merchant. If the transaction is successful during the retry policy, access is granted from the date and time the transaction is successfully made. For example, on a 1 week recurring payment frequency, which fails initially at 10am on the 1st April, but successfully bills at 15:30 on 1st April will next be billed at 15:30 on the 7th April. During the period of retrying a failed transaction, the consumer will not be granted access to the service until a successful transaction is made.
Billing retries are not allowed at the point of purchase. However, for recurring payments a limited retry strategy may be used for payments that utilise a free trial period or additional payments attempted after the first one, when access to the MNO billing systems is not available. When used, there is an exponential back-off policy up to 8 days (14 attempts). This means that a payment is attempted at increasing intervals to the previous until the 14th attempt has been made. Attempts are made at: [block:parameters] { "data": { "h-0": "Attempt number", "h-1": "Time in minutes", "0-0": "1", "1-0": "2", "2-0": "3", "3-0": "4", "4-0": "5", "5-0": "6", "6-0": "7", "7-0": "8", "8-0": "9", "9-0": "10", "10-0": "11", "11-0": "12", "12-0": "13", "13-0": "14", "0-1": "2", "1-1": "4", "2-1": "8", "3-1": "16", "4-1": "32", "5-1": "64", "6-1": "128", "7-1": "256", "8-1": "512", "9-1": "1024", "10-1": "2048", "11-1": "4096", "12-1": "8192", "13-1": "16384" }, "cols": 2, "rows": 14 } [/block] [block:api-header] { "type": "basic", "title": "Recurring Payment retry policy" } [/block] Recurring Payment transactions are made on the anniversary of the previous charge. For example, a recurring payment with a frequency of 1 week made at 10am on the 1st of April will next be billed at 10am on the 7th April. On the anniversary of a recurring payment, if the transaction fails for any reason and a retry period has not been set up, paid access will expire and the merchant will be sent a notification. Otherwise, a transaction will fail and then be retried using an exponential back off approach. If the transaction reaches the end of the retry policy and has still not billed successfully, a transaction failed status will be sent to the merchant. If the transaction is successful during the retry policy, access is granted from the date and time the transaction is successfully made. For example, on a 1 week recurring payment frequency, which fails initially at 10am on the 1st April, but successfully bills at 15:30 on 1st April will next be billed at 15:30 on the 7th April. During the period of retrying a failed transaction, the consumer will not be granted access to the service until a successful transaction is made.
{"__v":10,"_id":"5524f5bdd919032b0057ac55","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"Below are the scenarios where a SMS receipt message will be issued to the consumer by ImpulsePay. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Consumer completes Paywall purchase process\"\n}\n[/block]\nThis mandatory receipt message is sent immediately upon completion of the purchase process. \n\nThe default message text is as follows:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"FreeMsg: You have paid £<price> for <ServiceName> from <Merchant> (visited at <time>) HELP? <Helpline> or <EmailAddress>\",\n      \"language\": \"text\",\n      \"name\": \"Reciept Msg\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Consumer initiates a Recurring Payment\"\n}\n[/block]\nThis mandatory receipt message is sent immediately upon completion of the Recurring Payment opt-in process.\n\nThe default message text is as follows:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"FreeMsg: You have joined <ServiceName> for £<price> per <period> from <MerchantName> until you text STOP to <shortcode> to opt out. HELP? <Helpline>\",\n      \"language\": \"text\",\n      \"name\": \"Reciept Msg\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Consumer hits £20 spend on Recurring Payment cycle\"\n}\n[/block]\nThis mandatory reminder message is sent once a consumer has spent £20 since either opting in to recurring payments or their last reminder message was sent. \n\nThe default message text is as follows:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"FreeMsg: Reminder. You joined <ServiceName> for £<price> per <period> from <Merchant> until you text STOP to <shortcode>. HELP? <Helpline>\",\n      \"language\": \"text\",\n      \"name\": \"Reminder Msg\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Consumer reaches 1 month in Recurring Payment cycle\"\n}\n[/block]\nThis mandatory reminder message is sent once a consumer has reached a duration of 1 month since opting in to the recurring payment cycle or their last reminder message was sent.\n\nThe default message text is as follows:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"FreeMsg: Reminder. You joined <ServiceName> for £<price> per <Period> from <Merchant> until you text STOP to <shortcode>. HELP? <Helpline>\",\n      \"language\": \"text\",\n      \"name\": \"Reminder Msg\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Consumer initiates a Recurring Payment with initial free trial period\"\n}\n[/block]\nThis mandatory receipt message is sent within 15 minutes of consumer completion of the Recurring Payment opt-in process.\n\nThe default message text is as follows:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"FreeMsg: You have joined <ServiceName> for £<price> per <period> from <Merchant> until you text STOP to <shortcode> to opt out. HELP? <Helpline>\",\n      \"language\": \"html\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Customising Receipt Messages\"\n}\n[/block]\nUpon request, ImpulsePay can use a customised message. \nThese messages must contain the following elements and remain 160 characters or less.\n\n**Receipt Message** \n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"\\\\#xx:xx\",\n    \"0-1\": \"Tariff amount, including £ sign\",\n    \"1-0\": \"\\\\#servicename#\",\n    \"2-0\": \"\\\\#merchantname#\",\n    \"3-0\": \"\\\\#helpline#\\\"\",\n    \"1-1\": \"Service name specified in the settings page\",\n    \"2-1\": \"Merchant name that was specified during the account set up\",\n    \"3-1\": \"Helpline number that was specified during the account set up\"\n  },\n  \"cols\": 2,\n  \"rows\": 4\n}\n[/block]\nIf these parameters are not included, then the following default is used:\n\nFreeMsg: You have paid #xx.xx for #servicename# from #merchantname# (visited at ##:##) HELP? #helpline# or #help@emailaddress.com\n[block:api-header]\n{\n  \"type\": \"basic\"\n}\n[/block]\n**Welcome Message**\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"\\\\#xx.xx\",\n    \"1-0\": \"\\\\#servicename\\\\#\",\n    \"2-0\": \"\\\\#merchantname\\\\#\",\n    \"3-0\": \"\\\\#helpline\\\\#\",\n    \"4-0\": \"\\\\#optout\\\\#\",\n    \"5-0\": \"\\\\#frequency\\\\#\",\n    \"6-0\": \"\\\\#period\\\\#\",\n    \"0-1\": \"Tariff amount, including £ sign\",\n    \"1-1\": \"Service name specified in the settings page\",\n    \"2-1\": \"Merchant name that was specified during the account set up\",\n    \"3-1\": \"Helpline number that was specified during the account set up\",\n    \"4-1\": \"This will be replaced with 'STOP to 89365'\",\n    \"5-1\": \"The frequency of the recurring payments. If this is set to 1 then it will be 'per' [week/month] otherwise it will be 'per X' [week/month].\",\n    \"6-1\": \"The period of the recurring payments, either 'month' or 'week' with an 's' added for plural alternatives.\"\n  },\n  \"cols\": 2,\n  \"rows\": 7\n}\n[/block]\nIf these parameters are not included, then the following default is used:\n\nFreeMsg: You have joined #servicename# for #xx.xx #frequency# #period# from #merchantname# until you text #optout# to opt out. HELP? #helpline#\n[block:api-header]\n{\n  \"type\": \"basic\"\n}\n[/block]\n**Reminder Message**\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"\\\\#xx.xx\",\n    \"1-0\": \"\\\\#servicename\\\\#\",\n    \"2-0\": \"\\\\#merchantname\\\\#\",\n    \"3-0\": \"\\\\#helpline\\\\#\",\n    \"4-0\": \"\\\\#optout\\\\#\",\n    \"5-0\": \"\\\\#frequency\\\\#\",\n    \"6-0\": \"\\\\#period\\\\#\",\n    \"0-1\": \"Tariff amount, including £ sign\",\n    \"1-1\": \"Service name specified in the settings page\",\n    \"2-1\": \"Merchant name that was specified during the account set up\",\n    \"3-1\": \"Helpline number that was specified during the account set up\",\n    \"4-1\": \"This will be replaced with 'STOP to 89365'\",\n    \"5-1\": \"The frequency of the recurring payments. If this is set to 1 then it will be 'per' [week/month] otherwise it will be 'per X' [week/month].\",\n    \"6-1\": \"The period of the recurring payments, either 'month' or 'week' with an 's' added for plural alternatives.\"\n  },\n  \"cols\": 2,\n  \"rows\": 7\n}\n[/block]\nIf these parameters are not included, then the following default is used:\n\nFreeMsg: Reminder. You joined #servicename# for #xx.xx #frequency# #period# from #merchantname# until you text #optout# to opt out. HELP? #helpline#\n[block:api-header]\n{\n  \"type\": \"basic\"\n}\n[/block]\n** Access URL**\nAn access URL can be provided to the consumer in the receipt, welcome or reminder messages. This will provide the consumer with a link that will take them to the same success page URL when the transaction occurred. \n\nThe URL should be specified in the following format:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://m.domain.com/#ACCESSURL#\",\n      \"language\": \"http\"\n    }\n  ]\n}\n[/block]\nThe URL domain should point to the ImpulsePay servers. If the access URL is being used on a recurring payment then the last interaction date will be updated to the current date and the 120 day rule will reset.","category":"5524f5bcd919032b0057ac35","createdAt":"2015-02-24T18:40:17.337Z","excerpt":"Information on text receipts and reminders issued to consumers","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":5,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"receipt-messages","sync_unique":"","title":"Receipts & Reminders","type":"basic","updates":[],"user":"54eb3aaedf7add210007b26a","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Receipts & Reminders

Information on text receipts and reminders issued to consumers

Below are the scenarios where a SMS receipt message will be issued to the consumer by ImpulsePay. [block:api-header] { "type": "basic", "title": "Consumer completes Paywall purchase process" } [/block] This mandatory receipt message is sent immediately upon completion of the purchase process. The default message text is as follows: [block:code] { "codes": [ { "code": "FreeMsg: You have paid £<price> for <ServiceName> from <Merchant> (visited at <time>) HELP? <Helpline> or <EmailAddress>", "language": "text", "name": "Reciept Msg" } ] } [/block] [block:api-header] { "type": "basic", "title": "Consumer initiates a Recurring Payment" } [/block] This mandatory receipt message is sent immediately upon completion of the Recurring Payment opt-in process. The default message text is as follows: [block:code] { "codes": [ { "code": "FreeMsg: You have joined <ServiceName> for £<price> per <period> from <MerchantName> until you text STOP to <shortcode> to opt out. HELP? <Helpline>", "language": "text", "name": "Reciept Msg" } ] } [/block] [block:api-header] { "type": "basic", "title": "Consumer hits £20 spend on Recurring Payment cycle" } [/block] This mandatory reminder message is sent once a consumer has spent £20 since either opting in to recurring payments or their last reminder message was sent. The default message text is as follows: [block:code] { "codes": [ { "code": "FreeMsg: Reminder. You joined <ServiceName> for £<price> per <period> from <Merchant> until you text STOP to <shortcode>. HELP? <Helpline>", "language": "text", "name": "Reminder Msg" } ] } [/block] [block:api-header] { "type": "basic", "title": "Consumer reaches 1 month in Recurring Payment cycle" } [/block] This mandatory reminder message is sent once a consumer has reached a duration of 1 month since opting in to the recurring payment cycle or their last reminder message was sent. The default message text is as follows: [block:code] { "codes": [ { "code": "FreeMsg: Reminder. You joined <ServiceName> for £<price> per <Period> from <Merchant> until you text STOP to <shortcode>. HELP? <Helpline>", "language": "text", "name": "Reminder Msg" } ] } [/block] [block:api-header] { "type": "basic", "title": "Consumer initiates a Recurring Payment with initial free trial period" } [/block] This mandatory receipt message is sent within 15 minutes of consumer completion of the Recurring Payment opt-in process. The default message text is as follows: [block:code] { "codes": [ { "code": "FreeMsg: You have joined <ServiceName> for £<price> per <period> from <Merchant> until you text STOP to <shortcode> to opt out. HELP? <Helpline>", "language": "html" } ] } [/block] [block:api-header] { "type": "basic", "title": "Customising Receipt Messages" } [/block] Upon request, ImpulsePay can use a customised message. These messages must contain the following elements and remain 160 characters or less. **Receipt Message** [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "\\#xx:xx", "0-1": "Tariff amount, including £ sign", "1-0": "\\#servicename#", "2-0": "\\#merchantname#", "3-0": "\\#helpline#\"", "1-1": "Service name specified in the settings page", "2-1": "Merchant name that was specified during the account set up", "3-1": "Helpline number that was specified during the account set up" }, "cols": 2, "rows": 4 } [/block] If these parameters are not included, then the following default is used: FreeMsg: You have paid #xx.xx for #servicename# from #merchantname# (visited at ##:##) HELP? #helpline# or #help@emailaddress.com [block:api-header] { "type": "basic" } [/block] **Welcome Message** [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "\\#xx.xx", "1-0": "\\#servicename\\#", "2-0": "\\#merchantname\\#", "3-0": "\\#helpline\\#", "4-0": "\\#optout\\#", "5-0": "\\#frequency\\#", "6-0": "\\#period\\#", "0-1": "Tariff amount, including £ sign", "1-1": "Service name specified in the settings page", "2-1": "Merchant name that was specified during the account set up", "3-1": "Helpline number that was specified during the account set up", "4-1": "This will be replaced with 'STOP to 89365'", "5-1": "The frequency of the recurring payments. If this is set to 1 then it will be 'per' [week/month] otherwise it will be 'per X' [week/month].", "6-1": "The period of the recurring payments, either 'month' or 'week' with an 's' added for plural alternatives." }, "cols": 2, "rows": 7 } [/block] If these parameters are not included, then the following default is used: FreeMsg: You have joined #servicename# for #xx.xx #frequency# #period# from #merchantname# until you text #optout# to opt out. HELP? #helpline# [block:api-header] { "type": "basic" } [/block] **Reminder Message** [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "\\#xx.xx", "1-0": "\\#servicename\\#", "2-0": "\\#merchantname\\#", "3-0": "\\#helpline\\#", "4-0": "\\#optout\\#", "5-0": "\\#frequency\\#", "6-0": "\\#period\\#", "0-1": "Tariff amount, including £ sign", "1-1": "Service name specified in the settings page", "2-1": "Merchant name that was specified during the account set up", "3-1": "Helpline number that was specified during the account set up", "4-1": "This will be replaced with 'STOP to 89365'", "5-1": "The frequency of the recurring payments. If this is set to 1 then it will be 'per' [week/month] otherwise it will be 'per X' [week/month].", "6-1": "The period of the recurring payments, either 'month' or 'week' with an 's' added for plural alternatives." }, "cols": 2, "rows": 7 } [/block] If these parameters are not included, then the following default is used: FreeMsg: Reminder. You joined #servicename# for #xx.xx #frequency# #period# from #merchantname# until you text #optout# to opt out. HELP? #helpline# [block:api-header] { "type": "basic" } [/block] ** Access URL** An access URL can be provided to the consumer in the receipt, welcome or reminder messages. This will provide the consumer with a link that will take them to the same success page URL when the transaction occurred. The URL should be specified in the following format: [block:code] { "codes": [ { "code": "http://m.domain.com/#ACCESSURL#", "language": "http" } ] } [/block] The URL domain should point to the ImpulsePay servers. If the access URL is being used on a recurring payment then the last interaction date will be updated to the current date and the 120 day rule will reset.
Below are the scenarios where a SMS receipt message will be issued to the consumer by ImpulsePay. [block:api-header] { "type": "basic", "title": "Consumer completes Paywall purchase process" } [/block] This mandatory receipt message is sent immediately upon completion of the purchase process. The default message text is as follows: [block:code] { "codes": [ { "code": "FreeMsg: You have paid £<price> for <ServiceName> from <Merchant> (visited at <time>) HELP? <Helpline> or <EmailAddress>", "language": "text", "name": "Reciept Msg" } ] } [/block] [block:api-header] { "type": "basic", "title": "Consumer initiates a Recurring Payment" } [/block] This mandatory receipt message is sent immediately upon completion of the Recurring Payment opt-in process. The default message text is as follows: [block:code] { "codes": [ { "code": "FreeMsg: You have joined <ServiceName> for £<price> per <period> from <MerchantName> until you text STOP to <shortcode> to opt out. HELP? <Helpline>", "language": "text", "name": "Reciept Msg" } ] } [/block] [block:api-header] { "type": "basic", "title": "Consumer hits £20 spend on Recurring Payment cycle" } [/block] This mandatory reminder message is sent once a consumer has spent £20 since either opting in to recurring payments or their last reminder message was sent. The default message text is as follows: [block:code] { "codes": [ { "code": "FreeMsg: Reminder. You joined <ServiceName> for £<price> per <period> from <Merchant> until you text STOP to <shortcode>. HELP? <Helpline>", "language": "text", "name": "Reminder Msg" } ] } [/block] [block:api-header] { "type": "basic", "title": "Consumer reaches 1 month in Recurring Payment cycle" } [/block] This mandatory reminder message is sent once a consumer has reached a duration of 1 month since opting in to the recurring payment cycle or their last reminder message was sent. The default message text is as follows: [block:code] { "codes": [ { "code": "FreeMsg: Reminder. You joined <ServiceName> for £<price> per <Period> from <Merchant> until you text STOP to <shortcode>. HELP? <Helpline>", "language": "text", "name": "Reminder Msg" } ] } [/block] [block:api-header] { "type": "basic", "title": "Consumer initiates a Recurring Payment with initial free trial period" } [/block] This mandatory receipt message is sent within 15 minutes of consumer completion of the Recurring Payment opt-in process. The default message text is as follows: [block:code] { "codes": [ { "code": "FreeMsg: You have joined <ServiceName> for £<price> per <period> from <Merchant> until you text STOP to <shortcode> to opt out. HELP? <Helpline>", "language": "html" } ] } [/block] [block:api-header] { "type": "basic", "title": "Customising Receipt Messages" } [/block] Upon request, ImpulsePay can use a customised message. These messages must contain the following elements and remain 160 characters or less. **Receipt Message** [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "\\#xx:xx", "0-1": "Tariff amount, including £ sign", "1-0": "\\#servicename#", "2-0": "\\#merchantname#", "3-0": "\\#helpline#\"", "1-1": "Service name specified in the settings page", "2-1": "Merchant name that was specified during the account set up", "3-1": "Helpline number that was specified during the account set up" }, "cols": 2, "rows": 4 } [/block] If these parameters are not included, then the following default is used: FreeMsg: You have paid #xx.xx for #servicename# from #merchantname# (visited at ##:##) HELP? #helpline# or #help@emailaddress.com [block:api-header] { "type": "basic" } [/block] **Welcome Message** [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "\\#xx.xx", "1-0": "\\#servicename\\#", "2-0": "\\#merchantname\\#", "3-0": "\\#helpline\\#", "4-0": "\\#optout\\#", "5-0": "\\#frequency\\#", "6-0": "\\#period\\#", "0-1": "Tariff amount, including £ sign", "1-1": "Service name specified in the settings page", "2-1": "Merchant name that was specified during the account set up", "3-1": "Helpline number that was specified during the account set up", "4-1": "This will be replaced with 'STOP to 89365'", "5-1": "The frequency of the recurring payments. If this is set to 1 then it will be 'per' [week/month] otherwise it will be 'per X' [week/month].", "6-1": "The period of the recurring payments, either 'month' or 'week' with an 's' added for plural alternatives." }, "cols": 2, "rows": 7 } [/block] If these parameters are not included, then the following default is used: FreeMsg: You have joined #servicename# for #xx.xx #frequency# #period# from #merchantname# until you text #optout# to opt out. HELP? #helpline# [block:api-header] { "type": "basic" } [/block] **Reminder Message** [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "\\#xx.xx", "1-0": "\\#servicename\\#", "2-0": "\\#merchantname\\#", "3-0": "\\#helpline\\#", "4-0": "\\#optout\\#", "5-0": "\\#frequency\\#", "6-0": "\\#period\\#", "0-1": "Tariff amount, including £ sign", "1-1": "Service name specified in the settings page", "2-1": "Merchant name that was specified during the account set up", "3-1": "Helpline number that was specified during the account set up", "4-1": "This will be replaced with 'STOP to 89365'", "5-1": "The frequency of the recurring payments. If this is set to 1 then it will be 'per' [week/month] otherwise it will be 'per X' [week/month].", "6-1": "The period of the recurring payments, either 'month' or 'week' with an 's' added for plural alternatives." }, "cols": 2, "rows": 7 } [/block] If these parameters are not included, then the following default is used: FreeMsg: Reminder. You joined #servicename# for #xx.xx #frequency# #period# from #merchantname# until you text #optout# to opt out. HELP? #helpline# [block:api-header] { "type": "basic" } [/block] ** Access URL** An access URL can be provided to the consumer in the receipt, welcome or reminder messages. This will provide the consumer with a link that will take them to the same success page URL when the transaction occurred. The URL should be specified in the following format: [block:code] { "codes": [ { "code": "http://m.domain.com/#ACCESSURL#", "language": "http" } ] } [/block] The URL domain should point to the ImpulsePay servers. If the access URL is being used on a recurring payment then the last interaction date will be updated to the current date and the 120 day rule will reset.
{"__v":4,"_id":"5524f5bdd919032b0057ac52","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"url":""},"body":"For time-based access, it is expected that consumers will come back to the service at various times during their paid period of access.\n\nAccess is monitored by AccountID and FriendlyName value, therefore FriendlyName can be shared across different RouteIDs to ensure that either a single or recurring payment is the same for all, or in the case of different FriendlyName values, is different to all.\n\nIf a consumer attempts to pay but has access through a previous payment, ImpulsePay will return a 170 status code to the merchant to inform them of this. In the case of a recurring payment, concerning inactivity rules, ImpulsePay will extend the inactivity counter and send a 160 status code to the merchant.","category":"5524f5bcd919032b0057ac35","createdAt":"2015-02-23T14:57:52.905Z","excerpt":"Allowing access to returning users based on a timed access period","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":6,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"returning-user-access","sync_unique":"","title":"Returning User Access","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Returning User Access

Allowing access to returning users based on a timed access period

For time-based access, it is expected that consumers will come back to the service at various times during their paid period of access. Access is monitored by AccountID and FriendlyName value, therefore FriendlyName can be shared across different RouteIDs to ensure that either a single or recurring payment is the same for all, or in the case of different FriendlyName values, is different to all. If a consumer attempts to pay but has access through a previous payment, ImpulsePay will return a 170 status code to the merchant to inform them of this. In the case of a recurring payment, concerning inactivity rules, ImpulsePay will extend the inactivity counter and send a 160 status code to the merchant.
For time-based access, it is expected that consumers will come back to the service at various times during their paid period of access. Access is monitored by AccountID and FriendlyName value, therefore FriendlyName can be shared across different RouteIDs to ensure that either a single or recurring payment is the same for all, or in the case of different FriendlyName values, is different to all. If a consumer attempts to pay but has access through a previous payment, ImpulsePay will return a 170 status code to the merchant to inform them of this. In the case of a recurring payment, concerning inactivity rules, ImpulsePay will extend the inactivity counter and send a 160 status code to the merchant.
{"__v":11,"_id":"5524f5bdd919032b0057ac57","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"url":""},"body":"As part of the rules that govern this payment flow, the consumer's MSISDN may not be passed to the merchant following a transaction made on a 3G data connection. This is to provide additional security to protect the consumer from data protection breaches or misuse of data.\n\nTo help merchants identify a consumer, ImpulsePay will provide an MSISDNalias for a MSISDN. This is a 12 digit number starting with 440 and will never overlap with a UK mobile number which starts with '447'.\n\nConsumers may provide merchants with their MSISDN independently of ImpulsePay, for example when making a customer care call to a merchant. In this scenario, ImpulsePay provides a MSISDNalias lookup API to match the MSISDN to an Alias, enabling the merchant to match corresponding transactions on their systems. \n\nIf a merchant already knows a MSISDN and wishes to send a marketing message to consumers via ImpulsePay then a consumer's actual MSISDN will be returned in the billing notifications in these cases. This is because the consumer has provided their MSISDN independently to the merchant.","category":"5524f5bcd919032b0057ac35","createdAt":"2015-03-06T15:43:53.729Z","excerpt":"Information on consumer's details and what merchant's receive from ImpulsePay","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":7,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"msisdn-alaising","sync_unique":"","title":"MSISDN Aliasing","type":"basic","updates":[],"user":"54eb3aaedf7add210007b26a","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

MSISDN Aliasing

Information on consumer's details and what merchant's receive from ImpulsePay

As part of the rules that govern this payment flow, the consumer's MSISDN may not be passed to the merchant following a transaction made on a 3G data connection. This is to provide additional security to protect the consumer from data protection breaches or misuse of data. To help merchants identify a consumer, ImpulsePay will provide an MSISDNalias for a MSISDN. This is a 12 digit number starting with 440 and will never overlap with a UK mobile number which starts with '447'. Consumers may provide merchants with their MSISDN independently of ImpulsePay, for example when making a customer care call to a merchant. In this scenario, ImpulsePay provides a MSISDNalias lookup API to match the MSISDN to an Alias, enabling the merchant to match corresponding transactions on their systems. If a merchant already knows a MSISDN and wishes to send a marketing message to consumers via ImpulsePay then a consumer's actual MSISDN will be returned in the billing notifications in these cases. This is because the consumer has provided their MSISDN independently to the merchant.
As part of the rules that govern this payment flow, the consumer's MSISDN may not be passed to the merchant following a transaction made on a 3G data connection. This is to provide additional security to protect the consumer from data protection breaches or misuse of data. To help merchants identify a consumer, ImpulsePay will provide an MSISDNalias for a MSISDN. This is a 12 digit number starting with 440 and will never overlap with a UK mobile number which starts with '447'. Consumers may provide merchants with their MSISDN independently of ImpulsePay, for example when making a customer care call to a merchant. In this scenario, ImpulsePay provides a MSISDNalias lookup API to match the MSISDN to an Alias, enabling the merchant to match corresponding transactions on their systems. If a merchant already knows a MSISDN and wishes to send a marketing message to consumers via ImpulsePay then a consumer's actual MSISDN will be returned in the billing notifications in these cases. This is because the consumer has provided their MSISDN independently to the merchant.
{"__v":6,"_id":"5524f5bdd919032b0057ac59","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"url":""},"body":"There are tariff restrictions on MVNO networks which may affect a merchant's service. The most popular MVNO networks are O2 Business, Tesco, GiffGaff and Virgin. These network operate a limited set of tariff price points and do not offer dynamic billing.\n\nTo ensure the consumer can still gain access to the service without hitting any errors, ImpulsePay will automatically detect if the consumer is coming from an O2 based MVNO (O2 business, Tesco Mobile or Giff Gaff) and then adjust the price point to the MVNO tariff. \n\nFor example, a normal user would be presented with a £6 price point, whereas an O2 MVNO user could be presented with a £5 price point instead. This functionality means merchants will not lose potential customers when the price point is not available. Without this functionality in place, the merchant would receive a 210 error for unsupported tariff.\n\nFor Virgin users, the service is billed at the MVNO price point when specified. It is not possible to detect a Virgin user prior to their purchase, so the only option to bill the MVNO tariff price point is once the initial billing has failed (due to the user being on Virgin).","category":"5524f5bcd919032b0057ac35","createdAt":"2015-03-12T10:36:05.055Z","excerpt":"Information and limitations when billing consumers on virtual networks","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":8,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"billing-on-mvnos","sync_unique":"","title":"Billing On MVNOs","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Billing On MVNOs

Information and limitations when billing consumers on virtual networks

There are tariff restrictions on MVNO networks which may affect a merchant's service. The most popular MVNO networks are O2 Business, Tesco, GiffGaff and Virgin. These network operate a limited set of tariff price points and do not offer dynamic billing. To ensure the consumer can still gain access to the service without hitting any errors, ImpulsePay will automatically detect if the consumer is coming from an O2 based MVNO (O2 business, Tesco Mobile or Giff Gaff) and then adjust the price point to the MVNO tariff. For example, a normal user would be presented with a £6 price point, whereas an O2 MVNO user could be presented with a £5 price point instead. This functionality means merchants will not lose potential customers when the price point is not available. Without this functionality in place, the merchant would receive a 210 error for unsupported tariff. For Virgin users, the service is billed at the MVNO price point when specified. It is not possible to detect a Virgin user prior to their purchase, so the only option to bill the MVNO tariff price point is once the initial billing has failed (due to the user being on Virgin).
There are tariff restrictions on MVNO networks which may affect a merchant's service. The most popular MVNO networks are O2 Business, Tesco, GiffGaff and Virgin. These network operate a limited set of tariff price points and do not offer dynamic billing. To ensure the consumer can still gain access to the service without hitting any errors, ImpulsePay will automatically detect if the consumer is coming from an O2 based MVNO (O2 business, Tesco Mobile or Giff Gaff) and then adjust the price point to the MVNO tariff. For example, a normal user would be presented with a £6 price point, whereas an O2 MVNO user could be presented with a £5 price point instead. This functionality means merchants will not lose potential customers when the price point is not available. Without this functionality in place, the merchant would receive a 210 error for unsupported tariff. For Virgin users, the service is billed at the MVNO price point when specified. It is not possible to detect a Virgin user prior to their purchase, so the only option to bill the MVNO tariff price point is once the initial billing has failed (due to the user being on Virgin).
{"__v":13,"_id":"552bf6fa7820b80d00aa4e3b","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"url":""},"body":"[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"Before configuring a service, Merchants will need to get access credentials to the ImpulsePay Dashboard by contacting their account manager.\",\n  \"title\": \"ImpulsePay Dashboard\",\n  \"sidebar\": true\n}\n[/block]\nA payment page is set up, submitted for compliance approval and launched using two pages on the Dashboard - the Editor page and the RouteID Settings page. \n\nThe Editor page allows merchants to select and customise a payment page template, add their own logo, designs and branding and select the parameters for the payment button, including price point and recurring payment details. \n\nOnce a payment page is finished, the merchant can submit the page for compliance approval. \n\nThe RouteID Setting page allows merchants to set up information required for a service to be launched, including success and failure URLs for the consumer to be forwarded to after payment, as well as a notification URLs for ImpulsePay to forward notifications to.\n[block:api-header]\n{\n  \"type\": \"basic\"\n}\n[/block]","category":"552bcf3c1f25d30d0085d5e5","createdAt":"2015-04-13T17:03:54.883Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":0,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"getting-started","sync_unique":"","title":"Overview","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Overview


[block:callout] { "type": "info", "body": "Before configuring a service, Merchants will need to get access credentials to the ImpulsePay Dashboard by contacting their account manager.", "title": "ImpulsePay Dashboard", "sidebar": true } [/block] A payment page is set up, submitted for compliance approval and launched using two pages on the Dashboard - the Editor page and the RouteID Settings page. The Editor page allows merchants to select and customise a payment page template, add their own logo, designs and branding and select the parameters for the payment button, including price point and recurring payment details. Once a payment page is finished, the merchant can submit the page for compliance approval. The RouteID Setting page allows merchants to set up information required for a service to be launched, including success and failure URLs for the consumer to be forwarded to after payment, as well as a notification URLs for ImpulsePay to forward notifications to. [block:api-header] { "type": "basic" } [/block]
[block:callout] { "type": "info", "body": "Before configuring a service, Merchants will need to get access credentials to the ImpulsePay Dashboard by contacting their account manager.", "title": "ImpulsePay Dashboard", "sidebar": true } [/block] A payment page is set up, submitted for compliance approval and launched using two pages on the Dashboard - the Editor page and the RouteID Settings page. The Editor page allows merchants to select and customise a payment page template, add their own logo, designs and branding and select the parameters for the payment button, including price point and recurring payment details. Once a payment page is finished, the merchant can submit the page for compliance approval. The RouteID Setting page allows merchants to set up information required for a service to be launched, including success and failure URLs for the consumer to be forwarded to after payment, as well as a notification URLs for ImpulsePay to forward notifications to. [block:api-header] { "type": "basic" } [/block]
{"__v":14,"_id":"552cd2b7c20d640d008a36f9","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"The following steps will help merchants create, customise and save a payment page template for using later when setting up a service on the RouteID Settings page. The Editor is also used to submit payment page designs for compliance approval. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Choosing Blank or Pre-made Templates\"\n}\n[/block]\nOn this screen, merchants can select either a blank payment page to add their own code or select from a range of pre-made HTML templates suited for different devices. \n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/afrrOrzQK2eBSpJkIUfY_Screen%20Shot%202015-05-08%20at%2014.31.48.png\",\n        \"Screen Shot 2015-05-08 at 14.31.48.png\",\n        \"812\",\n        \"691\",\n        \"#438947\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nBy selecting one of these pre-made templates or just a blank template, the merchant will then be directed onto the Editor page to further customise it or paste in existing HTML code.\n\nOnce a template draft has been saved in the Editor, it will appear back on the Template selection screen, underneath the default templates, along with live templates and templates awaiting approval.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Customising a payment page\"\n}\n[/block]\nOnce either a blank or pre-made template has been selected on the previous screen, merchants can use the Editor to add their own payment page HTML code. \n\n**Template Name**\n\nSet the name for the template. This will then appear on the template selection page and in the Config page when choosing which templates to use for individual devices. \n\n**Preview Mobile**\n\nEnter a mobile number for a preview link to be sent by text, to test mobile payment page designs. \n\n**Preview Mobile**\nOpens a new tab with a desktop preview of the payment page design. \n\n**Add Purchase Button**\n\nUse the Add Payment Button wizard to insert a compliant payment button into the payment page. The settings for the buttons can be applied using this tool, including the setup of recurring payments. \n\n**Submit for Approval**\n\nOnce the template is complete, merchants can submit the payment page for compliance approval, before the service can go live. \n\n**Delete**\n\nUsed to remove a payment page and also prevent it being used in any live services. \n\n**File Upload**\n\nAll CSS and Image files used on the payment page must be uploaded to ImpulsePay using the file upload tool. \n\n**Insert Image**\n\nOnce an image has been uploaded using the file upload tool, merchants can easily insert it by clicking insert image and selecting from the uploaded media.\n\n**Source URL**\n\nFor merchants using the dynamic content system and <dynamic> tags within the payment page, enter the URL for the copy of the payment page hosted on the merchant side. ImpulsePay will then call this source URL, check the dynamic content tags on the merchant's copy and apply the changes to the live copy on ImpulsePay's servers.","category":"552bcf3c1f25d30d0085d5e5","createdAt":"2015-04-14T08:41:27.304Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":1,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"editor-page","sync_unique":"","title":"Editor Page","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Editor Page


The following steps will help merchants create, customise and save a payment page template for using later when setting up a service on the RouteID Settings page. The Editor is also used to submit payment page designs for compliance approval. [block:api-header] { "type": "basic", "title": "Choosing Blank or Pre-made Templates" } [/block] On this screen, merchants can select either a blank payment page to add their own code or select from a range of pre-made HTML templates suited for different devices. [block:image] { "images": [ { "image": [ "https://files.readme.io/afrrOrzQK2eBSpJkIUfY_Screen%20Shot%202015-05-08%20at%2014.31.48.png", "Screen Shot 2015-05-08 at 14.31.48.png", "812", "691", "#438947", "" ] } ] } [/block] By selecting one of these pre-made templates or just a blank template, the merchant will then be directed onto the Editor page to further customise it or paste in existing HTML code. Once a template draft has been saved in the Editor, it will appear back on the Template selection screen, underneath the default templates, along with live templates and templates awaiting approval. [block:api-header] { "type": "basic", "title": "Customising a payment page" } [/block] Once either a blank or pre-made template has been selected on the previous screen, merchants can use the Editor to add their own payment page HTML code. **Template Name** Set the name for the template. This will then appear on the template selection page and in the Config page when choosing which templates to use for individual devices. **Preview Mobile** Enter a mobile number for a preview link to be sent by text, to test mobile payment page designs. **Preview Mobile** Opens a new tab with a desktop preview of the payment page design. **Add Purchase Button** Use the Add Payment Button wizard to insert a compliant payment button into the payment page. The settings for the buttons can be applied using this tool, including the setup of recurring payments. **Submit for Approval** Once the template is complete, merchants can submit the payment page for compliance approval, before the service can go live. **Delete** Used to remove a payment page and also prevent it being used in any live services. **File Upload** All CSS and Image files used on the payment page must be uploaded to ImpulsePay using the file upload tool. **Insert Image** Once an image has been uploaded using the file upload tool, merchants can easily insert it by clicking insert image and selecting from the uploaded media. **Source URL** For merchants using the dynamic content system and <dynamic> tags within the payment page, enter the URL for the copy of the payment page hosted on the merchant side. ImpulsePay will then call this source URL, check the dynamic content tags on the merchant's copy and apply the changes to the live copy on ImpulsePay's servers.
The following steps will help merchants create, customise and save a payment page template for using later when setting up a service on the RouteID Settings page. The Editor is also used to submit payment page designs for compliance approval. [block:api-header] { "type": "basic", "title": "Choosing Blank or Pre-made Templates" } [/block] On this screen, merchants can select either a blank payment page to add their own code or select from a range of pre-made HTML templates suited for different devices. [block:image] { "images": [ { "image": [ "https://files.readme.io/afrrOrzQK2eBSpJkIUfY_Screen%20Shot%202015-05-08%20at%2014.31.48.png", "Screen Shot 2015-05-08 at 14.31.48.png", "812", "691", "#438947", "" ] } ] } [/block] By selecting one of these pre-made templates or just a blank template, the merchant will then be directed onto the Editor page to further customise it or paste in existing HTML code. Once a template draft has been saved in the Editor, it will appear back on the Template selection screen, underneath the default templates, along with live templates and templates awaiting approval. [block:api-header] { "type": "basic", "title": "Customising a payment page" } [/block] Once either a blank or pre-made template has been selected on the previous screen, merchants can use the Editor to add their own payment page HTML code. **Template Name** Set the name for the template. This will then appear on the template selection page and in the Config page when choosing which templates to use for individual devices. **Preview Mobile** Enter a mobile number for a preview link to be sent by text, to test mobile payment page designs. **Preview Mobile** Opens a new tab with a desktop preview of the payment page design. **Add Purchase Button** Use the Add Payment Button wizard to insert a compliant payment button into the payment page. The settings for the buttons can be applied using this tool, including the setup of recurring payments. **Submit for Approval** Once the template is complete, merchants can submit the payment page for compliance approval, before the service can go live. **Delete** Used to remove a payment page and also prevent it being used in any live services. **File Upload** All CSS and Image files used on the payment page must be uploaded to ImpulsePay using the file upload tool. **Insert Image** Once an image has been uploaded using the file upload tool, merchants can easily insert it by clicking insert image and selecting from the uploaded media. **Source URL** For merchants using the dynamic content system and <dynamic> tags within the payment page, enter the URL for the copy of the payment page hosted on the merchant side. ImpulsePay will then call this source URL, check the dynamic content tags on the merchant's copy and apply the changes to the live copy on ImpulsePay's servers.
{"__v":22,"_id":"552cd31ec20d640d008a36fc","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Route Settings\"\n}\n[/block]\nThis section of the Settings page displays an encoded RouteID and URLKey for the service that is being configured. These Parameters are automatically generated when you set up a new service. Both of these parameters are needed in a properly formatted Service URL.\n\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Editing Route Settings\"\n}\n[/block]\nThis section contains important settings for handling consumers after a purchase is made as well as recieving billing notifications from ImpulsePay. \n\nThe name given in the **Service Name** field will be the service name given in receipt messages and recurring payment messages. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"URL configuration\"\n}\n[/block]\nThe **Success URL** is where ImpulsePay forwards consumers if a purchase is successfully made, or when a free trial is provided. \n\nThe **Failure URL** is where ImpulsePay forwards consumers if a purchase is not successful. \n\nThe **Notification URL** is where ImpulsePay sends billing notifications and alerts to the merchant, after a billing attempt has been made.\n\nThe **Timestamp Key** will be used to encode the timestamp ImpulsePay send to verify that a purchase has been made within the previous 5 minutes and that the access is valid. This is to prevent circumvention of payment. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Optional Alerts and Notifications\"\n}\n[/block]\n**Impression Alert** \n\nInsert a URL to receive an impression alert (See Notify Impression). \n\n**First Click Alert**\n\nInsert a URL to receive a First Click notification. (See Notify First Click). \n\n**3G connection Alert**\n\nInsert a URL to receive a 3G connection notification. (See 3G Connection Alert).\n\n**Black List URL**\n\nInsert a URL for ImpulsePay to call when checking whether a consumer is on a merchant's list of blocked MSISDNs.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Verification flow settings\"\n}\n[/block]\n**Auto Detect MSISDNs** \n\nSelect whether or not automatic MSISDN verification should be used. \n\n**Mobile Devices**\n\nSelect the backup verification method for mobile devices, when auto detection of the MSISDN is not possible. \n\n**iPad/Desktop**\n\nSelect the preferred verification method for tablet devices and desktops. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Additional route settings\"\n}\n[/block]\n**Request Marketing Opt-in**\n\nChoose whether the marketing opt-in tick box should appear in the header box.\n\n**Age Verify Users** \n\nChoose whether the service should age verify users before accepting payment.\n\n**Show Billing Page/Real Time Billing**\n\nEnable or disable the waiting screen whilst ImpulsePay is attempting to bill the consumer.\nIf disabled, consumers will be forwarded straight to success URL and the billing attempt will take place after.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Checkout configurator\"\n}\n[/block]\nThis section contains configuration for selection of payment page by device type and also allows merchants to setup A/B Split testing. \n\nMerchants can select from a drop down of approved saved templates which ones they want to use for each device type. When a different template is selected for Route B, the consumer will be shown either the route A or route B template depending on whether the second value of the current time (at the point when the page is loaded) is even or odd.","category":"552bcf3c1f25d30d0085d5e5","createdAt":"2015-04-14T08:43:10.904Z","excerpt":"Information on correctly set up a service","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":2,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"config-page","sync_unique":"","title":"RouteID Settings Page","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

RouteID Settings Page

Information on correctly set up a service

[block:api-header] { "type": "basic", "title": "Route Settings" } [/block] This section of the Settings page displays an encoded RouteID and URLKey for the service that is being configured. These Parameters are automatically generated when you set up a new service. Both of these parameters are needed in a properly formatted Service URL. [block:api-header] { "type": "basic", "title": "Editing Route Settings" } [/block] This section contains important settings for handling consumers after a purchase is made as well as recieving billing notifications from ImpulsePay. The name given in the **Service Name** field will be the service name given in receipt messages and recurring payment messages. [block:api-header] { "type": "basic", "title": "URL configuration" } [/block] The **Success URL** is where ImpulsePay forwards consumers if a purchase is successfully made, or when a free trial is provided. The **Failure URL** is where ImpulsePay forwards consumers if a purchase is not successful. The **Notification URL** is where ImpulsePay sends billing notifications and alerts to the merchant, after a billing attempt has been made. The **Timestamp Key** will be used to encode the timestamp ImpulsePay send to verify that a purchase has been made within the previous 5 minutes and that the access is valid. This is to prevent circumvention of payment. [block:api-header] { "type": "basic", "title": "Optional Alerts and Notifications" } [/block] **Impression Alert** Insert a URL to receive an impression alert (See Notify Impression). **First Click Alert** Insert a URL to receive a First Click notification. (See Notify First Click). **3G connection Alert** Insert a URL to receive a 3G connection notification. (See 3G Connection Alert). **Black List URL** Insert a URL for ImpulsePay to call when checking whether a consumer is on a merchant's list of blocked MSISDNs. [block:api-header] { "type": "basic", "title": "Verification flow settings" } [/block] **Auto Detect MSISDNs** Select whether or not automatic MSISDN verification should be used. **Mobile Devices** Select the backup verification method for mobile devices, when auto detection of the MSISDN is not possible. **iPad/Desktop** Select the preferred verification method for tablet devices and desktops. [block:api-header] { "type": "basic", "title": "Additional route settings" } [/block] **Request Marketing Opt-in** Choose whether the marketing opt-in tick box should appear in the header box. **Age Verify Users** Choose whether the service should age verify users before accepting payment. **Show Billing Page/Real Time Billing** Enable or disable the waiting screen whilst ImpulsePay is attempting to bill the consumer. If disabled, consumers will be forwarded straight to success URL and the billing attempt will take place after. [block:api-header] { "type": "basic", "title": "Checkout configurator" } [/block] This section contains configuration for selection of payment page by device type and also allows merchants to setup A/B Split testing. Merchants can select from a drop down of approved saved templates which ones they want to use for each device type. When a different template is selected for Route B, the consumer will be shown either the route A or route B template depending on whether the second value of the current time (at the point when the page is loaded) is even or odd.
[block:api-header] { "type": "basic", "title": "Route Settings" } [/block] This section of the Settings page displays an encoded RouteID and URLKey for the service that is being configured. These Parameters are automatically generated when you set up a new service. Both of these parameters are needed in a properly formatted Service URL. [block:api-header] { "type": "basic", "title": "Editing Route Settings" } [/block] This section contains important settings for handling consumers after a purchase is made as well as recieving billing notifications from ImpulsePay. The name given in the **Service Name** field will be the service name given in receipt messages and recurring payment messages. [block:api-header] { "type": "basic", "title": "URL configuration" } [/block] The **Success URL** is where ImpulsePay forwards consumers if a purchase is successfully made, or when a free trial is provided. The **Failure URL** is where ImpulsePay forwards consumers if a purchase is not successful. The **Notification URL** is where ImpulsePay sends billing notifications and alerts to the merchant, after a billing attempt has been made. The **Timestamp Key** will be used to encode the timestamp ImpulsePay send to verify that a purchase has been made within the previous 5 minutes and that the access is valid. This is to prevent circumvention of payment. [block:api-header] { "type": "basic", "title": "Optional Alerts and Notifications" } [/block] **Impression Alert** Insert a URL to receive an impression alert (See Notify Impression). **First Click Alert** Insert a URL to receive a First Click notification. (See Notify First Click). **3G connection Alert** Insert a URL to receive a 3G connection notification. (See 3G Connection Alert). **Black List URL** Insert a URL for ImpulsePay to call when checking whether a consumer is on a merchant's list of blocked MSISDNs. [block:api-header] { "type": "basic", "title": "Verification flow settings" } [/block] **Auto Detect MSISDNs** Select whether or not automatic MSISDN verification should be used. **Mobile Devices** Select the backup verification method for mobile devices, when auto detection of the MSISDN is not possible. **iPad/Desktop** Select the preferred verification method for tablet devices and desktops. [block:api-header] { "type": "basic", "title": "Additional route settings" } [/block] **Request Marketing Opt-in** Choose whether the marketing opt-in tick box should appear in the header box. **Age Verify Users** Choose whether the service should age verify users before accepting payment. **Show Billing Page/Real Time Billing** Enable or disable the waiting screen whilst ImpulsePay is attempting to bill the consumer. If disabled, consumers will be forwarded straight to success URL and the billing attempt will take place after. [block:api-header] { "type": "basic", "title": "Checkout configurator" } [/block] This section contains configuration for selection of payment page by device type and also allows merchants to setup A/B Split testing. Merchants can select from a drop down of approved saved templates which ones they want to use for each device type. When a different template is selected for Route B, the consumer will be shown either the route A or route B template depending on whether the second value of the current time (at the point when the page is loaded) is even or odd.
{"__v":15,"_id":"560e60cecac9dc0d007af7ec","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Positioning Payforit Header in 'Embed' style\"\n}\n[/block]\nTo achieve an 'embed' style payment page design, where the Payforit Headerbox can be positioned above the charge notification and purchase button, merchants should place the tag < headerbox /> above the purchase button HTML code. For example: \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<headerbox />\\n<button type=\\\"charge\\\" \\n        data-friendlyname=\\\"Example\\\" \\n        data-ctatext=\\\"Get access now\\\" \\n        data-secondctatext=\\\"Enter site\\\" \\n        data-buttoncolour=\\\"018500\\\"  \\n        data-secondbuttoncolour=\\\"00127D\\\"\\n       \\tdata-buttonpadding=\\\"10\\\"\\n        data-edgesize=\\\"7\\\"\\n        data-accessperiod=\\\"\\\" \\n        data-billperiod=\\\"week\\\" \\n        data-tariff=\\\"500\\\"  \\n        data-frequency=\\\"1\\\"  \\n        data-cncolour=\\\"ffffff\\\" \\n        data-recurringtime=\\\"week\\\" \\n        data-description=\\\"Description\\\" \\n        name=\\\"step1\\\">\\n</button>\\t\",\n      \"language\": \"html\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"PWID, TemplateID and TemplateName global variables on payment page\"\n}\n[/block]\nA unique PWID is generated for each user session on a payment page. The PWID is available as a global JS variable when the payment page is loaded, with the variable name of PWID. This variable can then be used for background processes to help merchants identify each individual interaction at any given time. Also available on the page as JS variables are the TemplateID and TemplateName of the payment page used. These can then be easily used purposes such for on-page tracking. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Payment Page post-first click actions\"\n}\n[/block]\nMerchants are now able to modify page elements once the first purchase button has been clicked. To allow this, we have declared an empty JS function which is called once the first button is clicked. Merchants are able to intercept this function and add their own desired behavior to the page. \n\nAfter the first button has been clicked, we will call a function called ‘ButtonHook’ and pass in any string that is included in a new, optional ‘data-label’ attribute in the tag. We will also pass in one of the following Flow Methods as an attribute, so that merchants can perform actions depending on which flow is being used:\n\nMobileData \nMT Link\nIVR Call\nMO Msg \n\nFor example, the following tag, used for competition services, on a mobile data connection:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<button type=\\\"charge\\\" \\ndata-label=\\\"ABCarea\\\" \\ndata-closingdate=\\\"2015-12-31 10:00\\\" \\ndata-friendlyname=\\\"Button 1\\\" \\ndata-ctatext=\\\"4,6,8\\\" \\ndata-accessperiod=\\\"\\\" \\ndata-billperiod=\\\"single\\\" \\ndata-buttoncolour=\\\"03415a\\\" \\ndata-secondctatext=\\\"Confirm\\\" \\ndata-secondbuttoncolour=\\\"338c18\\\"\\ndata-tariff=\\\"100\\\" \\ndata-question=\\\"How many spider legs?\\\">\\n</button>\",\n      \"language\": \"html\"\n    }\n  ]\n}\n[/block]\nWill then attempt to call the JS function ButtonHook(‘ABCarea’, 'MobileData') once the user clicks the first button. Merchants can then define their own ButtonHook function to intercept the function call.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Hiding Payforit Header on non-payforit prelanding pages\"\n}\n[/block]\nThe Payforit Header box should only be shown when the purchase buttons are displayed on the page. For services that use 'pre-landing' pages, the Payforit Header should be hidden. \n\nMerchants can target the css of the Header by using the ID #PayforitHeader.","category":"552bcf3c1f25d30d0085d5e5","createdAt":"2015-10-02T10:47:42.669Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":3,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"first-click-events","sync_unique":"","title":"Advanced Features","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Advanced Features


[block:api-header] { "type": "basic", "title": "Positioning Payforit Header in 'Embed' style" } [/block] To achieve an 'embed' style payment page design, where the Payforit Headerbox can be positioned above the charge notification and purchase button, merchants should place the tag < headerbox /> above the purchase button HTML code. For example: [block:code] { "codes": [ { "code": "<headerbox />\n<button type=\"charge\" \n data-friendlyname=\"Example\" \n data-ctatext=\"Get access now\" \n data-secondctatext=\"Enter site\" \n data-buttoncolour=\"018500\" \n data-secondbuttoncolour=\"00127D\"\n \tdata-buttonpadding=\"10\"\n data-edgesize=\"7\"\n data-accessperiod=\"\" \n data-billperiod=\"week\" \n data-tariff=\"500\" \n data-frequency=\"1\" \n data-cncolour=\"ffffff\" \n data-recurringtime=\"week\" \n data-description=\"Description\" \n name=\"step1\">\n</button>\t", "language": "html" } ] } [/block] [block:api-header] { "type": "basic", "title": "PWID, TemplateID and TemplateName global variables on payment page" } [/block] A unique PWID is generated for each user session on a payment page. The PWID is available as a global JS variable when the payment page is loaded, with the variable name of PWID. This variable can then be used for background processes to help merchants identify each individual interaction at any given time. Also available on the page as JS variables are the TemplateID and TemplateName of the payment page used. These can then be easily used purposes such for on-page tracking. [block:api-header] { "type": "basic", "title": "Payment Page post-first click actions" } [/block] Merchants are now able to modify page elements once the first purchase button has been clicked. To allow this, we have declared an empty JS function which is called once the first button is clicked. Merchants are able to intercept this function and add their own desired behavior to the page. After the first button has been clicked, we will call a function called ‘ButtonHook’ and pass in any string that is included in a new, optional ‘data-label’ attribute in the tag. We will also pass in one of the following Flow Methods as an attribute, so that merchants can perform actions depending on which flow is being used: MobileData MT Link IVR Call MO Msg For example, the following tag, used for competition services, on a mobile data connection: [block:code] { "codes": [ { "code": "<button type=\"charge\" \ndata-label=\"ABCarea\" \ndata-closingdate=\"2015-12-31 10:00\" \ndata-friendlyname=\"Button 1\" \ndata-ctatext=\"4,6,8\" \ndata-accessperiod=\"\" \ndata-billperiod=\"single\" \ndata-buttoncolour=\"03415a\" \ndata-secondctatext=\"Confirm\" \ndata-secondbuttoncolour=\"338c18\"\ndata-tariff=\"100\" \ndata-question=\"How many spider legs?\">\n</button>", "language": "html" } ] } [/block] Will then attempt to call the JS function ButtonHook(‘ABCarea’, 'MobileData') once the user clicks the first button. Merchants can then define their own ButtonHook function to intercept the function call. [block:api-header] { "type": "basic", "title": "Hiding Payforit Header on non-payforit prelanding pages" } [/block] The Payforit Header box should only be shown when the purchase buttons are displayed on the page. For services that use 'pre-landing' pages, the Payforit Header should be hidden. Merchants can target the css of the Header by using the ID #PayforitHeader.
[block:api-header] { "type": "basic", "title": "Positioning Payforit Header in 'Embed' style" } [/block] To achieve an 'embed' style payment page design, where the Payforit Headerbox can be positioned above the charge notification and purchase button, merchants should place the tag < headerbox /> above the purchase button HTML code. For example: [block:code] { "codes": [ { "code": "<headerbox />\n<button type=\"charge\" \n data-friendlyname=\"Example\" \n data-ctatext=\"Get access now\" \n data-secondctatext=\"Enter site\" \n data-buttoncolour=\"018500\" \n data-secondbuttoncolour=\"00127D\"\n \tdata-buttonpadding=\"10\"\n data-edgesize=\"7\"\n data-accessperiod=\"\" \n data-billperiod=\"week\" \n data-tariff=\"500\" \n data-frequency=\"1\" \n data-cncolour=\"ffffff\" \n data-recurringtime=\"week\" \n data-description=\"Description\" \n name=\"step1\">\n</button>\t", "language": "html" } ] } [/block] [block:api-header] { "type": "basic", "title": "PWID, TemplateID and TemplateName global variables on payment page" } [/block] A unique PWID is generated for each user session on a payment page. The PWID is available as a global JS variable when the payment page is loaded, with the variable name of PWID. This variable can then be used for background processes to help merchants identify each individual interaction at any given time. Also available on the page as JS variables are the TemplateID and TemplateName of the payment page used. These can then be easily used purposes such for on-page tracking. [block:api-header] { "type": "basic", "title": "Payment Page post-first click actions" } [/block] Merchants are now able to modify page elements once the first purchase button has been clicked. To allow this, we have declared an empty JS function which is called once the first button is clicked. Merchants are able to intercept this function and add their own desired behavior to the page. After the first button has been clicked, we will call a function called ‘ButtonHook’ and pass in any string that is included in a new, optional ‘data-label’ attribute in the tag. We will also pass in one of the following Flow Methods as an attribute, so that merchants can perform actions depending on which flow is being used: MobileData MT Link IVR Call MO Msg For example, the following tag, used for competition services, on a mobile data connection: [block:code] { "codes": [ { "code": "<button type=\"charge\" \ndata-label=\"ABCarea\" \ndata-closingdate=\"2015-12-31 10:00\" \ndata-friendlyname=\"Button 1\" \ndata-ctatext=\"4,6,8\" \ndata-accessperiod=\"\" \ndata-billperiod=\"single\" \ndata-buttoncolour=\"03415a\" \ndata-secondctatext=\"Confirm\" \ndata-secondbuttoncolour=\"338c18\"\ndata-tariff=\"100\" \ndata-question=\"How many spider legs?\">\n</button>", "language": "html" } ] } [/block] Will then attempt to call the JS function ButtonHook(‘ABCarea’, 'MobileData') once the user clicks the first button. Merchants can then define their own ButtonHook function to intercept the function call. [block:api-header] { "type": "basic", "title": "Hiding Payforit Header on non-payforit prelanding pages" } [/block] The Payforit Header box should only be shown when the purchase buttons are displayed on the page. For services that use 'pre-landing' pages, the Payforit Header should be hidden. Merchants can target the css of the Header by using the ID #PayforitHeader.
{"__v":30,"_id":"560e5a4039fad419002ae165","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"The following example code can be used to create a purchase button on a payment page. \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<button type=\\\"charge\\\" \\ndata-ctaverb=\\\"buy\\\"\\ndata-cncolour=\\\"ffffff\\\" \\ndata-description=\\\"Superwidgets\\\" \\ndata-cntext1=\\\"#ChargeNotification# test\\\" \\ndata-cntext2=\\\" test #ChargeNotification#\\\" \\ndata-friendlyname=\\\"Button1\\\" \\ndata-buttoncolour=\\\"03415a\\\" \\ndata-buttongradient=\\\"267820\\\" \\ndata-secondbuttongradient=\\\"36C900\\\" \\ndata-secondbuttoncolour=\\\"498c3f\\\" \\ndata-buttonpadding=\\\"10\\\"\\ndata-accessperiod=\\\"\\\" \\ndata-billperiod=\\\"single\\\" \\ndata-tariff=\\\"100\\\"\\ndata-mvno=\\\"100\\\"></button> \",\n      \"language\": \"html\"\n    }\n  ]\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Attribute Name\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Requirement\",\n    \"0-0\": \"type\",\n    \"0-1\": \"A default attribute. Must be set to charge.\",\n    \"0-2\": \"Mandatory\",\n    \"1-0\": \"data-ctaverb\",\n    \"h-3\": \"Options\",\n    \"1-1\": \"Sets the verb to be used in the charge notification text.\",\n    \"1-2\": \"Optional. \\nDefaults to Buy if not specified\",\n    \"1-3\": \"Buy, Donate, Deposit, Enter, Vote\",\n    \"2-0\": \"data-cncolour\",\n    \"2-1\": \"Sets charge notification colour. Must be set to either FFFFF if used on a black background or 000000 if used on a white background.\",\n    \"2-2\": \"Mandatory.\",\n    \"3-0\": \"data-description\",\n    \"3-1\": \"Sets the production description text used in the charge notification.\",\n    \"3-2\": \"Mandatory\",\n    \"4-0\": \"data-cntext1\",\n    \"4-1\": \"Allows text to be wrapped around the charge notification text (See below for instructions)\",\n    \"4-2\": \"Optional\",\n    \"6-0\": \"data-friendlyname\",\n    \"6-1\": \"A unique identifier for the button, specified by the merchant\",\n    \"6-2\": \"Mandatory\",\n    \"7-0\": \"data-buttoncolour\",\n    \"7-1\": \"A 6 character hex code (without the #) for the first button colour\",\n    \"7-2\": \"Mandatory\",\n    \"9-0\": \"data-buttongradient\",\n    \"9-1\": \"A 6 character hex code (without the #) which controls gradient for the first button\",\n    \"9-2\": \"Optional\",\n    \"11-0\": \"data-accessperiod\",\n    \"11-1\": \"A digit to define the access period, in conjunction with bill period.\",\n    \"11-2\": \"Optional\",\n    \"11-3\": \"1, 2, 3\",\n    \"12-0\": \"data-billperiod\",\n    \"12-1\": \"A string to define the billing period for access. Default as Single.\",\n    \"12-2\": \"Mandatory\",\n    \"12-3\": \"single (default), day, week, month\",\n    \"16-0\": \"data-tariff\",\n    \"16-1\": \"The price point in pence to be displayed on the button\",\n    \"16-2\": \"Mandatory\",\n    \"16-3\": \"100 (£1)\",\n    \"18-0\": \"data-buttonBorder\",\n    \"18-1\": \"A 6 character hex code which controls the colour of the first button border.\",\n    \"18-2\": \"Optional, limited to FFFFFF or 000000\",\n    \"17-0\": \"data-mvno\",\n    \"17-1\": \"A lower rollback price point in pence to be charged if the tariff cannot be charged on an MVNO user\",\n    \"17-2\": \"Optional\",\n    \"17-3\": \"\",\n    \"14-0\": \"data-frequency\",\n    \"15-0\": \"data-recurringtime\",\n    \"14-1\": \"A digit to define the billing frequency, in pairing with data-recurringtime\",\n    \"15-1\": \"A string to define the billing frequency for recurring payments\",\n    \"14-2\": \"Optional\",\n    \"15-2\": \"Optional\",\n    \"14-3\": \"1,2, 3\",\n    \"15-3\": \"week, month\",\n    \"5-0\": \"data-cntext2\",\n    \"5-1\": \"Allows text to be wrapped around the confirmation text (See below for instructions)\",\n    \"5-2\": \"Optional\",\n    \"8-0\": \"data-secondbuttoncolour\",\n    \"8-1\": \"A 6 character hex code (without the #) for the second button colour\",\n    \"8-2\": \"Mandatory\",\n    \"10-0\": \"data-secondbuttongradient\",\n    \"10-1\": \"A 6 character hex code (without the #) which controls gradient for the second button\",\n    \"10-2\": \"Optional\",\n    \"19-0\": \"data-secondButtonBorder\",\n    \"19-1\": \"A 6 character hex code which controls the colour of the second button border.\",\n    \"19-2\": \"Optional, limited to FFFFFF or 000000\",\n    \"20-0\": \"data-recurringCharge\",\n    \"21-0\": \"data-initialPeriod\",\n    \"20-2\": \"Optional, int between 10-3000\",\n    \"21-2\": \"Optional, 1d, 1w, 1m\",\n    \"20-3\": \"25\",\n    \"21-1\": \"A string to define how long the initial charge lasts for, where an initial charge is more or less than subsequent recurring payments.\",\n    \"20-1\": \"When charging a different initial tariff to the subsequent recurring payments, recurringCharge defines the subsequent tariffs. When defined, Data-tariff then becomes the initial charge amount.\",\n    \"21-3\": \"1w\",\n    \"13-0\": \"data-freetrial\",\n    \"13-1\": \"A string to define the length of a free trial period (minimum 1 hr)\",\n    \"13-2\": \"Optional\",\n    \"13-3\": \"1h, 1d, 1w\",\n    \"3-3\": \"Characters A-Z, a-z, 0-9, punctuation allowed.\",\n    \"22-0\": \"data-buttonpadding\",\n    \"22-1\": \"An int to define how much padding in pixels should be applied to the purchase button. Only 10px or 20px allowed. Defaults to 20 if not specified.\",\n    \"22-2\": \"Optional\",\n    \"22-3\": \"10, 20\"\n  },\n  \"cols\": 4,\n  \"rows\": 23\n}\n[/block]\nThe Payforit Header box should only be shown when the purchase buttons are displayed on the page. For services that use 'pre-landing' pages, the Payforit Header should be hidden. \n\nMerchants can target the css of the Header by using the ID #PayforitHeader. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Adding product description to charge notification\"\n}\n[/block]\nThe charge notification text now requires a product description to be included and is adjusted to match the appropriate verb used (e.g. donate, enter, buy etc).\n\nThis can be added using the tag **data-description=\"super widgets\"** and the product description will be inserted to the charge notification. \n\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Wrapping text around charge notification\"\n}\n[/block]\nThe charge notification appears over the first button and the second button. Merchants can wrap text around both charge notifications. \n\nMerchants should use **data-cntext1** for the first charge notification and **data-cntext2** for the second charge notification parameters. #ChargeNotification# should be used a place holder for the actual charge notification text. \n\nFor example, adding the following attributes to the payment button tags:\ndata-cntext1=\"Example Text. #ChargeNotification#\" \ndata-cntext2=\"#ChargeNotification#. Example Text.\"\n\nWill be rendered as\nFirst Charge Notification:\n**Example Text. Buy Super widgets.** \nSecond Charge Notification:\n**Buy super widgets. Example Text.**\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Purchase Button Gradient\"\n}\n[/block]\nAn optional tag can now be specified in the button tags to set the starting gradient level of the purchase button. \n\nThis is **data-buttongradient** for the first button and** data-secondbuttongradient** for the second. The value should be a 6 digit hex (e.g. FFFFFF) and must be within a 2:1 contrast of the corresponding button colour, otherwise it will be ignored. The button colour also must exceed a 5:1 contrast of the charge notification area colour.\n\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Enable Recurring Payments\"\n}\n[/block]\nUsing data-accessperiod and data-billperiod, merchants can enable recurring payments. \n\nTo set a recurring payment for once a week, set data-accessperiod to \"1\" and data-billperiod to \"WEEK\". \n\n\n\nMerchants can select which action verb they wish to use on the initial button, from the choices of Donate, Deposit, Enter or Vote. Buy will be the default used. \n\nTo specify a phrase, an optional **data-ctaverb** should be added to the button tags with either Donate, Deposit, Enter or Vote as the parameter. \n\nSubscriptions will continue to use 'Subscribe now for £x per [week|month].","category":"552bcf3c1f25d30d0085d5e5","createdAt":"2015-10-02T10:19:44.972Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":4,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"purchase-button-area-configuration","sync_unique":"","title":"Button Parameters","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Button Parameters


The following example code can be used to create a purchase button on a payment page. [block:code] { "codes": [ { "code": "<button type=\"charge\" \ndata-ctaverb=\"buy\"\ndata-cncolour=\"ffffff\" \ndata-description=\"Superwidgets\" \ndata-cntext1=\"#ChargeNotification# test\" \ndata-cntext2=\" test #ChargeNotification#\" \ndata-friendlyname=\"Button1\" \ndata-buttoncolour=\"03415a\" \ndata-buttongradient=\"267820\" \ndata-secondbuttongradient=\"36C900\" \ndata-secondbuttoncolour=\"498c3f\" \ndata-buttonpadding=\"10\"\ndata-accessperiod=\"\" \ndata-billperiod=\"single\" \ndata-tariff=\"100\"\ndata-mvno=\"100\"></button> ", "language": "html" } ] } [/block] [block:parameters] { "data": { "h-0": "Attribute Name", "h-1": "Description", "h-2": "Requirement", "0-0": "type", "0-1": "A default attribute. Must be set to charge.", "0-2": "Mandatory", "1-0": "data-ctaverb", "h-3": "Options", "1-1": "Sets the verb to be used in the charge notification text.", "1-2": "Optional. \nDefaults to Buy if not specified", "1-3": "Buy, Donate, Deposit, Enter, Vote", "2-0": "data-cncolour", "2-1": "Sets charge notification colour. Must be set to either FFFFF if used on a black background or 000000 if used on a white background.", "2-2": "Mandatory.", "3-0": "data-description", "3-1": "Sets the production description text used in the charge notification.", "3-2": "Mandatory", "4-0": "data-cntext1", "4-1": "Allows text to be wrapped around the charge notification text (See below for instructions)", "4-2": "Optional", "6-0": "data-friendlyname", "6-1": "A unique identifier for the button, specified by the merchant", "6-2": "Mandatory", "7-0": "data-buttoncolour", "7-1": "A 6 character hex code (without the #) for the first button colour", "7-2": "Mandatory", "9-0": "data-buttongradient", "9-1": "A 6 character hex code (without the #) which controls gradient for the first button", "9-2": "Optional", "11-0": "data-accessperiod", "11-1": "A digit to define the access period, in conjunction with bill period.", "11-2": "Optional", "11-3": "1, 2, 3", "12-0": "data-billperiod", "12-1": "A string to define the billing period for access. Default as Single.", "12-2": "Mandatory", "12-3": "single (default), day, week, month", "16-0": "data-tariff", "16-1": "The price point in pence to be displayed on the button", "16-2": "Mandatory", "16-3": "100 (£1)", "18-0": "data-buttonBorder", "18-1": "A 6 character hex code which controls the colour of the first button border.", "18-2": "Optional, limited to FFFFFF or 000000", "17-0": "data-mvno", "17-1": "A lower rollback price point in pence to be charged if the tariff cannot be charged on an MVNO user", "17-2": "Optional", "17-3": "", "14-0": "data-frequency", "15-0": "data-recurringtime", "14-1": "A digit to define the billing frequency, in pairing with data-recurringtime", "15-1": "A string to define the billing frequency for recurring payments", "14-2": "Optional", "15-2": "Optional", "14-3": "1,2, 3", "15-3": "week, month", "5-0": "data-cntext2", "5-1": "Allows text to be wrapped around the confirmation text (See below for instructions)", "5-2": "Optional", "8-0": "data-secondbuttoncolour", "8-1": "A 6 character hex code (without the #) for the second button colour", "8-2": "Mandatory", "10-0": "data-secondbuttongradient", "10-1": "A 6 character hex code (without the #) which controls gradient for the second button", "10-2": "Optional", "19-0": "data-secondButtonBorder", "19-1": "A 6 character hex code which controls the colour of the second button border.", "19-2": "Optional, limited to FFFFFF or 000000", "20-0": "data-recurringCharge", "21-0": "data-initialPeriod", "20-2": "Optional, int between 10-3000", "21-2": "Optional, 1d, 1w, 1m", "20-3": "25", "21-1": "A string to define how long the initial charge lasts for, where an initial charge is more or less than subsequent recurring payments.", "20-1": "When charging a different initial tariff to the subsequent recurring payments, recurringCharge defines the subsequent tariffs. When defined, Data-tariff then becomes the initial charge amount.", "21-3": "1w", "13-0": "data-freetrial", "13-1": "A string to define the length of a free trial period (minimum 1 hr)", "13-2": "Optional", "13-3": "1h, 1d, 1w", "3-3": "Characters A-Z, a-z, 0-9, punctuation allowed.", "22-0": "data-buttonpadding", "22-1": "An int to define how much padding in pixels should be applied to the purchase button. Only 10px or 20px allowed. Defaults to 20 if not specified.", "22-2": "Optional", "22-3": "10, 20" }, "cols": 4, "rows": 23 } [/block] The Payforit Header box should only be shown when the purchase buttons are displayed on the page. For services that use 'pre-landing' pages, the Payforit Header should be hidden. Merchants can target the css of the Header by using the ID #PayforitHeader. [block:api-header] { "type": "basic", "title": "Adding product description to charge notification" } [/block] The charge notification text now requires a product description to be included and is adjusted to match the appropriate verb used (e.g. donate, enter, buy etc). This can be added using the tag **data-description="super widgets"** and the product description will be inserted to the charge notification. [block:api-header] { "type": "basic", "title": "Wrapping text around charge notification" } [/block] The charge notification appears over the first button and the second button. Merchants can wrap text around both charge notifications. Merchants should use **data-cntext1** for the first charge notification and **data-cntext2** for the second charge notification parameters. #ChargeNotification# should be used a place holder for the actual charge notification text. For example, adding the following attributes to the payment button tags: data-cntext1="Example Text. #ChargeNotification#" data-cntext2="#ChargeNotification#. Example Text." Will be rendered as First Charge Notification: **Example Text. Buy Super widgets.** Second Charge Notification: **Buy super widgets. Example Text.** [block:api-header] { "type": "basic", "title": "Purchase Button Gradient" } [/block] An optional tag can now be specified in the button tags to set the starting gradient level of the purchase button. This is **data-buttongradient** for the first button and** data-secondbuttongradient** for the second. The value should be a 6 digit hex (e.g. FFFFFF) and must be within a 2:1 contrast of the corresponding button colour, otherwise it will be ignored. The button colour also must exceed a 5:1 contrast of the charge notification area colour. [block:api-header] { "type": "basic", "title": "Enable Recurring Payments" } [/block] Using data-accessperiod and data-billperiod, merchants can enable recurring payments. To set a recurring payment for once a week, set data-accessperiod to "1" and data-billperiod to "WEEK". Merchants can select which action verb they wish to use on the initial button, from the choices of Donate, Deposit, Enter or Vote. Buy will be the default used. To specify a phrase, an optional **data-ctaverb** should be added to the button tags with either Donate, Deposit, Enter or Vote as the parameter. Subscriptions will continue to use 'Subscribe now for £x per [week|month].
The following example code can be used to create a purchase button on a payment page. [block:code] { "codes": [ { "code": "<button type=\"charge\" \ndata-ctaverb=\"buy\"\ndata-cncolour=\"ffffff\" \ndata-description=\"Superwidgets\" \ndata-cntext1=\"#ChargeNotification# test\" \ndata-cntext2=\" test #ChargeNotification#\" \ndata-friendlyname=\"Button1\" \ndata-buttoncolour=\"03415a\" \ndata-buttongradient=\"267820\" \ndata-secondbuttongradient=\"36C900\" \ndata-secondbuttoncolour=\"498c3f\" \ndata-buttonpadding=\"10\"\ndata-accessperiod=\"\" \ndata-billperiod=\"single\" \ndata-tariff=\"100\"\ndata-mvno=\"100\"></button> ", "language": "html" } ] } [/block] [block:parameters] { "data": { "h-0": "Attribute Name", "h-1": "Description", "h-2": "Requirement", "0-0": "type", "0-1": "A default attribute. Must be set to charge.", "0-2": "Mandatory", "1-0": "data-ctaverb", "h-3": "Options", "1-1": "Sets the verb to be used in the charge notification text.", "1-2": "Optional. \nDefaults to Buy if not specified", "1-3": "Buy, Donate, Deposit, Enter, Vote", "2-0": "data-cncolour", "2-1": "Sets charge notification colour. Must be set to either FFFFF if used on a black background or 000000 if used on a white background.", "2-2": "Mandatory.", "3-0": "data-description", "3-1": "Sets the production description text used in the charge notification.", "3-2": "Mandatory", "4-0": "data-cntext1", "4-1": "Allows text to be wrapped around the charge notification text (See below for instructions)", "4-2": "Optional", "6-0": "data-friendlyname", "6-1": "A unique identifier for the button, specified by the merchant", "6-2": "Mandatory", "7-0": "data-buttoncolour", "7-1": "A 6 character hex code (without the #) for the first button colour", "7-2": "Mandatory", "9-0": "data-buttongradient", "9-1": "A 6 character hex code (without the #) which controls gradient for the first button", "9-2": "Optional", "11-0": "data-accessperiod", "11-1": "A digit to define the access period, in conjunction with bill period.", "11-2": "Optional", "11-3": "1, 2, 3", "12-0": "data-billperiod", "12-1": "A string to define the billing period for access. Default as Single.", "12-2": "Mandatory", "12-3": "single (default), day, week, month", "16-0": "data-tariff", "16-1": "The price point in pence to be displayed on the button", "16-2": "Mandatory", "16-3": "100 (£1)", "18-0": "data-buttonBorder", "18-1": "A 6 character hex code which controls the colour of the first button border.", "18-2": "Optional, limited to FFFFFF or 000000", "17-0": "data-mvno", "17-1": "A lower rollback price point in pence to be charged if the tariff cannot be charged on an MVNO user", "17-2": "Optional", "17-3": "", "14-0": "data-frequency", "15-0": "data-recurringtime", "14-1": "A digit to define the billing frequency, in pairing with data-recurringtime", "15-1": "A string to define the billing frequency for recurring payments", "14-2": "Optional", "15-2": "Optional", "14-3": "1,2, 3", "15-3": "week, month", "5-0": "data-cntext2", "5-1": "Allows text to be wrapped around the confirmation text (See below for instructions)", "5-2": "Optional", "8-0": "data-secondbuttoncolour", "8-1": "A 6 character hex code (without the #) for the second button colour", "8-2": "Mandatory", "10-0": "data-secondbuttongradient", "10-1": "A 6 character hex code (without the #) which controls gradient for the second button", "10-2": "Optional", "19-0": "data-secondButtonBorder", "19-1": "A 6 character hex code which controls the colour of the second button border.", "19-2": "Optional, limited to FFFFFF or 000000", "20-0": "data-recurringCharge", "21-0": "data-initialPeriod", "20-2": "Optional, int between 10-3000", "21-2": "Optional, 1d, 1w, 1m", "20-3": "25", "21-1": "A string to define how long the initial charge lasts for, where an initial charge is more or less than subsequent recurring payments.", "20-1": "When charging a different initial tariff to the subsequent recurring payments, recurringCharge defines the subsequent tariffs. When defined, Data-tariff then becomes the initial charge amount.", "21-3": "1w", "13-0": "data-freetrial", "13-1": "A string to define the length of a free trial period (minimum 1 hr)", "13-2": "Optional", "13-3": "1h, 1d, 1w", "3-3": "Characters A-Z, a-z, 0-9, punctuation allowed.", "22-0": "data-buttonpadding", "22-1": "An int to define how much padding in pixels should be applied to the purchase button. Only 10px or 20px allowed. Defaults to 20 if not specified.", "22-2": "Optional", "22-3": "10, 20" }, "cols": 4, "rows": 23 } [/block] The Payforit Header box should only be shown when the purchase buttons are displayed on the page. For services that use 'pre-landing' pages, the Payforit Header should be hidden. Merchants can target the css of the Header by using the ID #PayforitHeader. [block:api-header] { "type": "basic", "title": "Adding product description to charge notification" } [/block] The charge notification text now requires a product description to be included and is adjusted to match the appropriate verb used (e.g. donate, enter, buy etc). This can be added using the tag **data-description="super widgets"** and the product description will be inserted to the charge notification. [block:api-header] { "type": "basic", "title": "Wrapping text around charge notification" } [/block] The charge notification appears over the first button and the second button. Merchants can wrap text around both charge notifications. Merchants should use **data-cntext1** for the first charge notification and **data-cntext2** for the second charge notification parameters. #ChargeNotification# should be used a place holder for the actual charge notification text. For example, adding the following attributes to the payment button tags: data-cntext1="Example Text. #ChargeNotification#" data-cntext2="#ChargeNotification#. Example Text." Will be rendered as First Charge Notification: **Example Text. Buy Super widgets.** Second Charge Notification: **Buy super widgets. Example Text.** [block:api-header] { "type": "basic", "title": "Purchase Button Gradient" } [/block] An optional tag can now be specified in the button tags to set the starting gradient level of the purchase button. This is **data-buttongradient** for the first button and** data-secondbuttongradient** for the second. The value should be a 6 digit hex (e.g. FFFFFF) and must be within a 2:1 contrast of the corresponding button colour, otherwise it will be ignored. The button colour also must exceed a 5:1 contrast of the charge notification area colour. [block:api-header] { "type": "basic", "title": "Enable Recurring Payments" } [/block] Using data-accessperiod and data-billperiod, merchants can enable recurring payments. To set a recurring payment for once a week, set data-accessperiod to "1" and data-billperiod to "WEEK". Merchants can select which action verb they wish to use on the initial button, from the choices of Donate, Deposit, Enter or Vote. Buy will be the default used. To specify a phrase, an optional **data-ctaverb** should be added to the button tags with either Donate, Deposit, Enter or Vote as the parameter. Subscriptions will continue to use 'Subscribe now for £x per [week|month].
{"__v":19,"_id":"55940c41fd29b92300c262b6","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"Competition services can be set up on PaymentPages using the following button structure. \n\n**Please note that when using this feature, the following applies:**\n\n- The competition button can only be added via the HTML source view. If you attempt to view the button in the editor view then you will see an incorrectly rendered button. The preview link can be used to view the page correctly.\n\n- A competition button is converted to an ‘AnswerBox’ which has a CSS class of ‘AnswerBox’. Inside this are the AnswerButton's which the consumer can click. \n\n- When an answer button is clicked, the entire answer box table (which also contains the pricing text) will be replaced with the second purchase button. The button will automatically adjust for the wifi flow specified in the settings configuration. \n\n- The mobile network operators apply additional styling requirements to the AnswerBox, AnswerButton’s and pricing text. These must be set up correctly before submitting the PaymentPage for approval.\n\n- If the closing date specified is either invalid or in the past then the PaymentPage will not load.\n\n- The consumer is charged regardless of their answer being correct or incorrect. This is to safe guard the skill element of the competition and prevents the consumer from guessing the answer. There should be an option to to allow the consumer to change their answer after they have entered but before they click the second purchase button.\n\n- Recurring payments may be used. These are called 'Prize Draws' as the consumer enters into an ongoing prize draw to win prizes, instead of a one off entry. Separate parameters listed below are required to enable this.\n \n- Additional rules apply for competition services above £10. Please contact ImpulsePay to discuss this before submitting a PaymentPage for approval.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Syntax\"\n}\n[/block]\nTo add a competition to a PaymentPage, please use the following button syntax:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<button \\ntype=\\\"charge\\\" \\ndata-closingdate=\\\"2015-07-31 10:00\\\"\\ndata-question=\\\"Example Question?\\\"\\ndata-friendlyname=\\\"Button 1\\\" \\ndata-ctatext=\\\"1,2,3\\\"  \\ndata-accessperiod=\\\"\\\" \\ndata-billperiod=\\\"single\\\" \\ndata-buttoncolour=\\\"03415a\\\" \\ndata-secondctatext=\\\"Confirm\\\" \\ndata-secondbuttoncolour=\\\"338c18\\\"\\ndata-tariff=\\\"110\\\" \\ndata-mvno=\\\"100\\\">\\n</button>\",\n      \"language\": \"html\"\n    }\n  ]\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"data-closingdate\",\n    \"1-0\": \"data-question\",\n    \"2-0\": \"data-friendlyname\",\n    \"3-0\": \"data-ctatext\",\n    \"4-0\": \"data-accessperiod\",\n    \"5-0\": \"data-billperiod\",\n    \"6-0\": \"data-buttoncolour\",\n    \"7-0\": \"data-secondctatext\",\n    \"8-0\": \"data-secondbuttoncolour\",\n    \"9-0\": \"data-tariff\",\n    \"10-0\": \"data-mvno\",\n    \"0-1\": \"The closing date for the competition. The PaymentPage will not be shown if this is invalid or in the past.\",\n    \"1-1\": \"Question the consumer is asked, which is used for tracking purposes and not displayed to the consumer.\",\n    \"2-1\": \"A name used to identify the competition and track duplicate entries against.\",\n    \"3-1\": \"The answer options to show in the AnswerBox's which should be comma delimited.\",\n    \"4-1\": \"Required field, please leave blank.\",\n    \"5-1\": \"Must be set to SINGLE\",\n    \"6-1\": \"The background hex colour for the AnswerButton's and PricingText.\",\n    \"7-1\": \"The call to action text displayed on the top line of the second opt in button.\",\n    \"8-1\": \"The background hex colour for the second opt in button. This must adhere to the colour contrast guidelines.\",\n    \"9-1\": \"The amount to charge for entry into the competition.\",\n    \"10-1\": \"An optional fall back amount to change if the user is on an MVNO.\",\n    \"0-2\": \"YYYY-MM-DD HH:MM\",\n    \"1-2\": \"25 characters that must be A-Z 0-9.,-? or space\",\n    \"2-2\": \"String - 30 characters\",\n    \"3-2\": \"String e.g 1,2,3\",\n    \"5-2\": \"\",\n    \"6-2\": \"FF0000\",\n    \"7-2\": \"String - 30 characters\",\n    \"8-2\": \"000000\",\n    \"9-2\": \"INT between 100 and 3000\",\n    \"10-2\": \"100, 150, 200, 250, 300, 350, 400, 450, 500, 1000\"\n  },\n  \"cols\": 3,\n  \"rows\": 11\n}\n[/block]\nWhen a billing notification is made after a purchase, the Note field is replaced with the following data: Q:<question>#A:<answer>#C:<YYYY-MM-DD HH:MM>. This is the question that was asked, the answer chosen and the closing date for entries.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Prize Draws\"\n}\n[/block]\nAdd the following additional parameters to the button tag to enable an ongoing prize draw to be offered.\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"data-frequency\",\n    \"1-0\": \"data-recurringtime\",\n    \"0-1\": \"The frequency of the recurring payments\",\n    \"0-2\": \"1\",\n    \"1-1\": \"The period to charge the recurring payments for, which should be either WEEK or MONTH\",\n    \"1-2\": \"WEEK\"\n  },\n  \"cols\": 3,\n  \"rows\": 2\n}\n[/block]\nWhen a billing notification is made after a purchase, the initial request's Note field is replaced with the following data: Q:<question>#A:<answer>#C:<YYYY-MM-DD HH:MM>. This is the question that was asked, the answer chosen and the closing date for entries.\n\nSubsequent notifications will be blank as the consumer is not required to answer another question before a recurring payment is made. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Targeting AnswerBox CSS\"\n}\n[/block]\nMerchants can style the three answerboxes by using the class .AnswerBox. The AnswerBox is formatted into a table on the payment page and can be targeted. \n\nFor example, the following CSS rule can be applied to change the sizing and colour of the answer buttons:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \".AnswerBox button[type=\\\"submit\\\"] {\\n background-color: #7D5698 !important;\\n   border: solid 3px #9582A5 !important;\\n    -webkit-border-radius: 5px !important;\\n    -moz-border-radius: 5px !important;\\n    border-radius: 5px !important;\\n    padding: 11px 18px !important;\\n    display: inline-block !important;\\n    font-family: arial !important;\\n    font-size: 59px !important;\\n    font-weight: bold !important;\\n    color: white !important;\\n    margin: 10px 5% !important;\\n    font-weight: bold !important;\\n    width: 83% !important;\\n}\\n\\n.AnswerBox tr td\\n{\\nwidth: 120px;\\n}\",\n      \"language\": \"css\"\n    }\n  ]\n}\n[/block]","category":"552bcf3c1f25d30d0085d5e5","createdAt":"2015-07-01T15:50:25.252Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":5,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"competition-services","sync_unique":"","title":"Competition Services","type":"basic","updates":[],"user":"54eb3aaedf7add210007b26a","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Competition Services


Competition services can be set up on PaymentPages using the following button structure. **Please note that when using this feature, the following applies:** - The competition button can only be added via the HTML source view. If you attempt to view the button in the editor view then you will see an incorrectly rendered button. The preview link can be used to view the page correctly. - A competition button is converted to an ‘AnswerBox’ which has a CSS class of ‘AnswerBox’. Inside this are the AnswerButton's which the consumer can click. - When an answer button is clicked, the entire answer box table (which also contains the pricing text) will be replaced with the second purchase button. The button will automatically adjust for the wifi flow specified in the settings configuration. - The mobile network operators apply additional styling requirements to the AnswerBox, AnswerButton’s and pricing text. These must be set up correctly before submitting the PaymentPage for approval. - If the closing date specified is either invalid or in the past then the PaymentPage will not load. - The consumer is charged regardless of their answer being correct or incorrect. This is to safe guard the skill element of the competition and prevents the consumer from guessing the answer. There should be an option to to allow the consumer to change their answer after they have entered but before they click the second purchase button. - Recurring payments may be used. These are called 'Prize Draws' as the consumer enters into an ongoing prize draw to win prizes, instead of a one off entry. Separate parameters listed below are required to enable this. - Additional rules apply for competition services above £10. Please contact ImpulsePay to discuss this before submitting a PaymentPage for approval. [block:api-header] { "type": "basic", "title": "Syntax" } [/block] To add a competition to a PaymentPage, please use the following button syntax: [block:code] { "codes": [ { "code": "<button \ntype=\"charge\" \ndata-closingdate=\"2015-07-31 10:00\"\ndata-question=\"Example Question?\"\ndata-friendlyname=\"Button 1\" \ndata-ctatext=\"1,2,3\" \ndata-accessperiod=\"\" \ndata-billperiod=\"single\" \ndata-buttoncolour=\"03415a\" \ndata-secondctatext=\"Confirm\" \ndata-secondbuttoncolour=\"338c18\"\ndata-tariff=\"110\" \ndata-mvno=\"100\">\n</button>", "language": "html" } ] } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "data-closingdate", "1-0": "data-question", "2-0": "data-friendlyname", "3-0": "data-ctatext", "4-0": "data-accessperiod", "5-0": "data-billperiod", "6-0": "data-buttoncolour", "7-0": "data-secondctatext", "8-0": "data-secondbuttoncolour", "9-0": "data-tariff", "10-0": "data-mvno", "0-1": "The closing date for the competition. The PaymentPage will not be shown if this is invalid or in the past.", "1-1": "Question the consumer is asked, which is used for tracking purposes and not displayed to the consumer.", "2-1": "A name used to identify the competition and track duplicate entries against.", "3-1": "The answer options to show in the AnswerBox's which should be comma delimited.", "4-1": "Required field, please leave blank.", "5-1": "Must be set to SINGLE", "6-1": "The background hex colour for the AnswerButton's and PricingText.", "7-1": "The call to action text displayed on the top line of the second opt in button.", "8-1": "The background hex colour for the second opt in button. This must adhere to the colour contrast guidelines.", "9-1": "The amount to charge for entry into the competition.", "10-1": "An optional fall back amount to change if the user is on an MVNO.", "0-2": "YYYY-MM-DD HH:MM", "1-2": "25 characters that must be A-Z 0-9.,-? or space", "2-2": "String - 30 characters", "3-2": "String e.g 1,2,3", "5-2": "", "6-2": "FF0000", "7-2": "String - 30 characters", "8-2": "000000", "9-2": "INT between 100 and 3000", "10-2": "100, 150, 200, 250, 300, 350, 400, 450, 500, 1000" }, "cols": 3, "rows": 11 } [/block] When a billing notification is made after a purchase, the Note field is replaced with the following data: Q:<question>#A:<answer>#C:<YYYY-MM-DD HH:MM>. This is the question that was asked, the answer chosen and the closing date for entries. [block:api-header] { "type": "basic", "title": "Prize Draws" } [/block] Add the following additional parameters to the button tag to enable an ongoing prize draw to be offered. [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "data-frequency", "1-0": "data-recurringtime", "0-1": "The frequency of the recurring payments", "0-2": "1", "1-1": "The period to charge the recurring payments for, which should be either WEEK or MONTH", "1-2": "WEEK" }, "cols": 3, "rows": 2 } [/block] When a billing notification is made after a purchase, the initial request's Note field is replaced with the following data: Q:<question>#A:<answer>#C:<YYYY-MM-DD HH:MM>. This is the question that was asked, the answer chosen and the closing date for entries. Subsequent notifications will be blank as the consumer is not required to answer another question before a recurring payment is made. [block:api-header] { "type": "basic", "title": "Targeting AnswerBox CSS" } [/block] Merchants can style the three answerboxes by using the class .AnswerBox. The AnswerBox is formatted into a table on the payment page and can be targeted. For example, the following CSS rule can be applied to change the sizing and colour of the answer buttons: [block:code] { "codes": [ { "code": ".AnswerBox button[type=\"submit\"] {\n background-color: #7D5698 !important;\n border: solid 3px #9582A5 !important;\n -webkit-border-radius: 5px !important;\n -moz-border-radius: 5px !important;\n border-radius: 5px !important;\n padding: 11px 18px !important;\n display: inline-block !important;\n font-family: arial !important;\n font-size: 59px !important;\n font-weight: bold !important;\n color: white !important;\n margin: 10px 5% !important;\n font-weight: bold !important;\n width: 83% !important;\n}\n\n.AnswerBox tr td\n{\nwidth: 120px;\n}", "language": "css" } ] } [/block]
Competition services can be set up on PaymentPages using the following button structure. **Please note that when using this feature, the following applies:** - The competition button can only be added via the HTML source view. If you attempt to view the button in the editor view then you will see an incorrectly rendered button. The preview link can be used to view the page correctly. - A competition button is converted to an ‘AnswerBox’ which has a CSS class of ‘AnswerBox’. Inside this are the AnswerButton's which the consumer can click. - When an answer button is clicked, the entire answer box table (which also contains the pricing text) will be replaced with the second purchase button. The button will automatically adjust for the wifi flow specified in the settings configuration. - The mobile network operators apply additional styling requirements to the AnswerBox, AnswerButton’s and pricing text. These must be set up correctly before submitting the PaymentPage for approval. - If the closing date specified is either invalid or in the past then the PaymentPage will not load. - The consumer is charged regardless of their answer being correct or incorrect. This is to safe guard the skill element of the competition and prevents the consumer from guessing the answer. There should be an option to to allow the consumer to change their answer after they have entered but before they click the second purchase button. - Recurring payments may be used. These are called 'Prize Draws' as the consumer enters into an ongoing prize draw to win prizes, instead of a one off entry. Separate parameters listed below are required to enable this. - Additional rules apply for competition services above £10. Please contact ImpulsePay to discuss this before submitting a PaymentPage for approval. [block:api-header] { "type": "basic", "title": "Syntax" } [/block] To add a competition to a PaymentPage, please use the following button syntax: [block:code] { "codes": [ { "code": "<button \ntype=\"charge\" \ndata-closingdate=\"2015-07-31 10:00\"\ndata-question=\"Example Question?\"\ndata-friendlyname=\"Button 1\" \ndata-ctatext=\"1,2,3\" \ndata-accessperiod=\"\" \ndata-billperiod=\"single\" \ndata-buttoncolour=\"03415a\" \ndata-secondctatext=\"Confirm\" \ndata-secondbuttoncolour=\"338c18\"\ndata-tariff=\"110\" \ndata-mvno=\"100\">\n</button>", "language": "html" } ] } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "data-closingdate", "1-0": "data-question", "2-0": "data-friendlyname", "3-0": "data-ctatext", "4-0": "data-accessperiod", "5-0": "data-billperiod", "6-0": "data-buttoncolour", "7-0": "data-secondctatext", "8-0": "data-secondbuttoncolour", "9-0": "data-tariff", "10-0": "data-mvno", "0-1": "The closing date for the competition. The PaymentPage will not be shown if this is invalid or in the past.", "1-1": "Question the consumer is asked, which is used for tracking purposes and not displayed to the consumer.", "2-1": "A name used to identify the competition and track duplicate entries against.", "3-1": "The answer options to show in the AnswerBox's which should be comma delimited.", "4-1": "Required field, please leave blank.", "5-1": "Must be set to SINGLE", "6-1": "The background hex colour for the AnswerButton's and PricingText.", "7-1": "The call to action text displayed on the top line of the second opt in button.", "8-1": "The background hex colour for the second opt in button. This must adhere to the colour contrast guidelines.", "9-1": "The amount to charge for entry into the competition.", "10-1": "An optional fall back amount to change if the user is on an MVNO.", "0-2": "YYYY-MM-DD HH:MM", "1-2": "25 characters that must be A-Z 0-9.,-? or space", "2-2": "String - 30 characters", "3-2": "String e.g 1,2,3", "5-2": "", "6-2": "FF0000", "7-2": "String - 30 characters", "8-2": "000000", "9-2": "INT between 100 and 3000", "10-2": "100, 150, 200, 250, 300, 350, 400, 450, 500, 1000" }, "cols": 3, "rows": 11 } [/block] When a billing notification is made after a purchase, the Note field is replaced with the following data: Q:<question>#A:<answer>#C:<YYYY-MM-DD HH:MM>. This is the question that was asked, the answer chosen and the closing date for entries. [block:api-header] { "type": "basic", "title": "Prize Draws" } [/block] Add the following additional parameters to the button tag to enable an ongoing prize draw to be offered. [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "data-frequency", "1-0": "data-recurringtime", "0-1": "The frequency of the recurring payments", "0-2": "1", "1-1": "The period to charge the recurring payments for, which should be either WEEK or MONTH", "1-2": "WEEK" }, "cols": 3, "rows": 2 } [/block] When a billing notification is made after a purchase, the initial request's Note field is replaced with the following data: Q:<question>#A:<answer>#C:<YYYY-MM-DD HH:MM>. This is the question that was asked, the answer chosen and the closing date for entries. Subsequent notifications will be blank as the consumer is not required to answer another question before a recurring payment is made. [block:api-header] { "type": "basic", "title": "Targeting AnswerBox CSS" } [/block] Merchants can style the three answerboxes by using the class .AnswerBox. The AnswerBox is formatted into a table on the payment page and can be targeted. For example, the following CSS rule can be applied to change the sizing and colour of the answer buttons: [block:code] { "codes": [ { "code": ".AnswerBox button[type=\"submit\"] {\n background-color: #7D5698 !important;\n border: solid 3px #9582A5 !important;\n -webkit-border-radius: 5px !important;\n -moz-border-radius: 5px !important;\n border-radius: 5px !important;\n padding: 11px 18px !important;\n display: inline-block !important;\n font-family: arial !important;\n font-size: 59px !important;\n font-weight: bold !important;\n color: white !important;\n margin: 10px 5% !important;\n font-weight: bold !important;\n width: 83% !important;\n}\n\n.AnswerBox tr td\n{\nwidth: 120px;\n}", "language": "css" } ] } [/block]
{"__v":8,"_id":"55969582430c481900db1b99","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"The PaymentPage platform operates a compliance upfront policy. All production-ready PaymentPages must be approved by ImpulsePay's independent compliance review to become available for live launch. \n\nThe review process happens in two stages. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Payment Page Submission and Internal Review\"\n}\n[/block]\nPaymentPages can be submitted in the PaymentPage Editor by clicking Submit for Approval. This should only be done once the merchant is satisfied that the PaymentPage is in a finished, production-ready state. \n\nThe PaymentPage is then reviewed internally by ImpulsePay to confirm that the PaymentPage is in a production-ready state. Feedback from ImpulsePay at this stage can be seen on the Compliance Report page, which can be accessed by clicking the Compliance Report button on the PaymentPage Editor. \n\nOnce the PaymentPage has been approved internally, it will be submitted to the first of two independent compliance partners for independent review. \n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Please Note\",\n  \"body\": \"Only production-ready PaymentPages should be submitted for approval. For the testing of PaymentPages, use Testmode (see Using Testmode).\",\n  \"sidebar\": true\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Independent Review\"\n}\n[/block]\nOnce the first stage is complete, both independent compliance partners will provide feedback and make corrective suggestions through the Compliance Report page on the PaymentPage Editor. \n\nMerchants should edit their PaymentPage within the Editor, according to feedback on the Compliance Report, before re-submitting their PaymentPage.","category":"552bcf3c1f25d30d0085d5e5","createdAt":"2015-07-03T14:00:34.099Z","excerpt":"Information on the process for getting PaymentPages approved for live production","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":6,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"compliance-approval-process","sync_unique":"","title":"Compliance Approval Process","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Compliance Approval Process

Information on the process for getting PaymentPages approved for live production

The PaymentPage platform operates a compliance upfront policy. All production-ready PaymentPages must be approved by ImpulsePay's independent compliance review to become available for live launch. The review process happens in two stages. [block:api-header] { "type": "basic", "title": "Payment Page Submission and Internal Review" } [/block] PaymentPages can be submitted in the PaymentPage Editor by clicking Submit for Approval. This should only be done once the merchant is satisfied that the PaymentPage is in a finished, production-ready state. The PaymentPage is then reviewed internally by ImpulsePay to confirm that the PaymentPage is in a production-ready state. Feedback from ImpulsePay at this stage can be seen on the Compliance Report page, which can be accessed by clicking the Compliance Report button on the PaymentPage Editor. Once the PaymentPage has been approved internally, it will be submitted to the first of two independent compliance partners for independent review. [block:callout] { "type": "warning", "title": "Please Note", "body": "Only production-ready PaymentPages should be submitted for approval. For the testing of PaymentPages, use Testmode (see Using Testmode).", "sidebar": true } [/block] [block:api-header] { "type": "basic", "title": "Independent Review" } [/block] Once the first stage is complete, both independent compliance partners will provide feedback and make corrective suggestions through the Compliance Report page on the PaymentPage Editor. Merchants should edit their PaymentPage within the Editor, according to feedback on the Compliance Report, before re-submitting their PaymentPage.
The PaymentPage platform operates a compliance upfront policy. All production-ready PaymentPages must be approved by ImpulsePay's independent compliance review to become available for live launch. The review process happens in two stages. [block:api-header] { "type": "basic", "title": "Payment Page Submission and Internal Review" } [/block] PaymentPages can be submitted in the PaymentPage Editor by clicking Submit for Approval. This should only be done once the merchant is satisfied that the PaymentPage is in a finished, production-ready state. The PaymentPage is then reviewed internally by ImpulsePay to confirm that the PaymentPage is in a production-ready state. Feedback from ImpulsePay at this stage can be seen on the Compliance Report page, which can be accessed by clicking the Compliance Report button on the PaymentPage Editor. Once the PaymentPage has been approved internally, it will be submitted to the first of two independent compliance partners for independent review. [block:callout] { "type": "warning", "title": "Please Note", "body": "Only production-ready PaymentPages should be submitted for approval. For the testing of PaymentPages, use Testmode (see Using Testmode).", "sidebar": true } [/block] [block:api-header] { "type": "basic", "title": "Independent Review" } [/block] Once the first stage is complete, both independent compliance partners will provide feedback and make corrective suggestions through the Compliance Report page on the PaymentPage Editor. Merchants should edit their PaymentPage within the Editor, according to feedback on the Compliance Report, before re-submitting their PaymentPage.
{"__v":18,"_id":"5524f5bdd919032b0057ac46","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"To access a merchant's payment page, consumers should be directed using the Service URL. \n\nThe inbound URL for a service should be structured as follows:\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Getting RouteIDs\",\n  \"body\": \"Merchants can create RouteIDs on the ImpulsePay dashboard by logging in and clicking create RouteID. The Service URL RouteID to use in the service URL is then shown at the top of his page next to the RouteID\",\n  \"sidebar\": true\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://m.domain.com/RouteID/CampaignID?URLKey={KEY}\",\n      \"language\": \"http\"\n    }\n  ]\n}\n[/block]\nThe following parameters can be used with this URL format\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"m.domain.com\",\n    \"0-1\": \"The merchant's domain\",\n    \"2-0\": \"CampaignID\",\n    \"5-0\": \"AffID\",\n    \"5-1\": \"Used to define multiple custom variables (using '-' as a delimiter) to capture custom affiliates tracking data. For example, AffID=AA-BB will result ‘AA’ and ‘BB’ parameters being stored for this request and returned to the merchant. The maximum Affiliate data that will be stored is limited to 250 characters.\",\n    \"2-1\": \"A custom ID used by the merchant to identify different traffic sources running on a service. This can between 1 and 15 0-9 or A-Z characters only.\",\n    \"9-0\": \"TestFail\",\n    \"9-1\": \"This will force a transaction to fail when set to Y and used in conjunction with TestMode.\",\n    \"3-0\": \"URLKey\",\n    \"4-0\": \"Note\",\n    \"6-0\": \"DeviceType\",\n    \"7-0\": \"TemplateID\",\n    \"6-1\": \"The device type to use for this request, which overrides the automated ones. The options can be Desktop, iPad, iPhone, Android, Mobile.\",\n    \"4-1\": \"The merchant can use the note for passing custom parameters through. These will be returned to the merchant in the billing notification. This can be a maximum of 250 characters.\",\n    \"0-2\": \"Mandatory\",\n    \"2-2\": \"Mandatory\",\n    \"3-2\": \"Mandatory\",\n    \"4-2\": \"Optional\",\n    \"1-2\": \"Mandatory\",\n    \"1-0\": \"RouteID\",\n    \"5-2\": \"Optional\",\n    \"6-2\": \"Optional\",\n    \"7-2\": \"Optional\",\n    \"9-2\": \"Optional\",\n    \"8-2\": \"Optional\",\n    \"8-0\": \"TestMode\",\n    \"1-1\": \"The Service URL RouteID specified on the Route Settings page. Ensure this is the Service URL RouteID value.\",\n    \"3-1\": \"The Key specified in the ImpulsePay dashboard\",\n    \"7-1\": \"The TemplateID for the template to use for this request. This template must be set to 'active' to allow billing, otherwise TestMode must also be specified.\",\n    \"8-1\": \"This is the token provided by ImpulsePay which allows Merchants to test services in a development environment.\",\n    \"h-2\": \"Requirement\"\n  },\n  \"cols\": 3,\n  \"rows\": 10\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"URL Error\",\n  \"body\": \"If the service URL does not contain a valid RouteID or CampaignID then the request will be redirected to the domain root.\",\n  \"sidebar\": true\n}\n[/block]","category":"5524f5bcd919032b0057ac36","createdAt":"2015-02-23T15:01:56.838Z","excerpt":"This is the URL advertised to consumers and used to access the service","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":0,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"inbound-service-url","sync_unique":"","title":"Service URL","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Service URL

This is the URL advertised to consumers and used to access the service

To access a merchant's payment page, consumers should be directed using the Service URL. The inbound URL for a service should be structured as follows: [block:callout] { "type": "info", "title": "Getting RouteIDs", "body": "Merchants can create RouteIDs on the ImpulsePay dashboard by logging in and clicking create RouteID. The Service URL RouteID to use in the service URL is then shown at the top of his page next to the RouteID", "sidebar": true } [/block] [block:code] { "codes": [ { "code": "http://m.domain.com/RouteID/CampaignID?URLKey={KEY}", "language": "http" } ] } [/block] The following parameters can be used with this URL format [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "m.domain.com", "0-1": "The merchant's domain", "2-0": "CampaignID", "5-0": "AffID", "5-1": "Used to define multiple custom variables (using '-' as a delimiter) to capture custom affiliates tracking data. For example, AffID=AA-BB will result ‘AA’ and ‘BB’ parameters being stored for this request and returned to the merchant. The maximum Affiliate data that will be stored is limited to 250 characters.", "2-1": "A custom ID used by the merchant to identify different traffic sources running on a service. This can between 1 and 15 0-9 or A-Z characters only.", "9-0": "TestFail", "9-1": "This will force a transaction to fail when set to Y and used in conjunction with TestMode.", "3-0": "URLKey", "4-0": "Note", "6-0": "DeviceType", "7-0": "TemplateID", "6-1": "The device type to use for this request, which overrides the automated ones. The options can be Desktop, iPad, iPhone, Android, Mobile.", "4-1": "The merchant can use the note for passing custom parameters through. These will be returned to the merchant in the billing notification. This can be a maximum of 250 characters.", "0-2": "Mandatory", "2-2": "Mandatory", "3-2": "Mandatory", "4-2": "Optional", "1-2": "Mandatory", "1-0": "RouteID", "5-2": "Optional", "6-2": "Optional", "7-2": "Optional", "9-2": "Optional", "8-2": "Optional", "8-0": "TestMode", "1-1": "The Service URL RouteID specified on the Route Settings page. Ensure this is the Service URL RouteID value.", "3-1": "The Key specified in the ImpulsePay dashboard", "7-1": "The TemplateID for the template to use for this request. This template must be set to 'active' to allow billing, otherwise TestMode must also be specified.", "8-1": "This is the token provided by ImpulsePay which allows Merchants to test services in a development environment.", "h-2": "Requirement" }, "cols": 3, "rows": 10 } [/block] [block:callout] { "type": "warning", "title": "URL Error", "body": "If the service URL does not contain a valid RouteID or CampaignID then the request will be redirected to the domain root.", "sidebar": true } [/block]
To access a merchant's payment page, consumers should be directed using the Service URL. The inbound URL for a service should be structured as follows: [block:callout] { "type": "info", "title": "Getting RouteIDs", "body": "Merchants can create RouteIDs on the ImpulsePay dashboard by logging in and clicking create RouteID. The Service URL RouteID to use in the service URL is then shown at the top of his page next to the RouteID", "sidebar": true } [/block] [block:code] { "codes": [ { "code": "http://m.domain.com/RouteID/CampaignID?URLKey={KEY}", "language": "http" } ] } [/block] The following parameters can be used with this URL format [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "m.domain.com", "0-1": "The merchant's domain", "2-0": "CampaignID", "5-0": "AffID", "5-1": "Used to define multiple custom variables (using '-' as a delimiter) to capture custom affiliates tracking data. For example, AffID=AA-BB will result ‘AA’ and ‘BB’ parameters being stored for this request and returned to the merchant. The maximum Affiliate data that will be stored is limited to 250 characters.", "2-1": "A custom ID used by the merchant to identify different traffic sources running on a service. This can between 1 and 15 0-9 or A-Z characters only.", "9-0": "TestFail", "9-1": "This will force a transaction to fail when set to Y and used in conjunction with TestMode.", "3-0": "URLKey", "4-0": "Note", "6-0": "DeviceType", "7-0": "TemplateID", "6-1": "The device type to use for this request, which overrides the automated ones. The options can be Desktop, iPad, iPhone, Android, Mobile.", "4-1": "The merchant can use the note for passing custom parameters through. These will be returned to the merchant in the billing notification. This can be a maximum of 250 characters.", "0-2": "Mandatory", "2-2": "Mandatory", "3-2": "Mandatory", "4-2": "Optional", "1-2": "Mandatory", "1-0": "RouteID", "5-2": "Optional", "6-2": "Optional", "7-2": "Optional", "9-2": "Optional", "8-2": "Optional", "8-0": "TestMode", "1-1": "The Service URL RouteID specified on the Route Settings page. Ensure this is the Service URL RouteID value.", "3-1": "The Key specified in the ImpulsePay dashboard", "7-1": "The TemplateID for the template to use for this request. This template must be set to 'active' to allow billing, otherwise TestMode must also be specified.", "8-1": "This is the token provided by ImpulsePay which allows Merchants to test services in a development environment.", "h-2": "Requirement" }, "cols": 3, "rows": 10 } [/block] [block:callout] { "type": "warning", "title": "URL Error", "body": "If the service URL does not contain a valid RouteID or CampaignID then the request will be redirected to the domain root.", "sidebar": true } [/block]
{"__v":11,"_id":"552fe8af633a5b0d00e99e5a","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"Upon a successful transaction being completed, ImpulsePay will forward the consumer to the Success URL specified by the merchant in the Config dashboard. \n\nThe MSISDN and Timestamp parameters are encrypted using a 24 character, Base64 Encryption Key specified by the merchant on the Settings/Create RouteID page on the Dashboard. \n\nMerchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.\n\nThe following parameters are also passed through to the merchant: \n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Data type\",\n    \"0-0\": \"PWID\",\n    \"1-0\": \"CampaignID\",\n    \"2-0\": \"Operator\",\n    \"3-0\": \"Status\",\n    \"4-0\": \"Note\",\n    \"5-0\": \"AffiliateID\",\n    \"6-0\": \"FriendlyName\",\n    \"7-0\": \"Timestamp\",\n    \"0-1\": \"ImpulsePay's unique identifier for the consumers purchase\",\n    \"4-1\": \"Custom parameters passed through from the initial interaction with the payment page\",\n    \"5-1\": \"Affiliate values passed through from the initial interaction with the payment page\",\n    \"6-1\": \"The value specified in the payment button to help identify the service\",\n    \"7-1\": \"The time when the purchase was made. If in the last 5 minutes, the access can be seen as valid. Encrypted using the Encryption Key specified on the Settings page.\",\n    \"2-1\": \"The mobile network operator for the consumer.\",\n    \"3-1\": \"The short status code for the status of the payment.\",\n    \"1-1\": \"The merchant's identifier for the campaign\",\n    \"0-2\": \"String - 75 characters\",\n    \"1-2\": \"String - 15 characters\",\n    \"2-2\": \"o2_uk,\\norange_uk,\\nthree_uk,\\ntmobile_uk,\\nvirgin_uk,\\nvodafone_uk,\",\n    \"3-2\": \"Int\",\n    \"4-2\": \"String - 250 characters\",\n    \"5-2\": \"String - 250 characters\",\n    \"6-2\": \"String - 30 characters\",\n    \"7-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"8-0\": \"Tariff\",\n    \"8-1\": \"The tariff (in pence) that the consumer has purchased.\",\n    \"8-2\": \"Int\",\n    \"9-0\": \"MSISDN\",\n    \"10-0\": \"MSISDNType\",\n    \"9-1\": \"The MSISDN or Alias for the consumer. This parameter is encoded using the Encryption Key specified on the Settings page.\",\n    \"10-1\": \"Flag to specify if this is a MSISDN or ALIAS being passed.\",\n    \"9-2\": \"Int\",\n    \"10-2\": \"ALIAS\\nMSISDN\"\n  },\n  \"cols\": 3,\n  \"rows\": 11\n}\n[/block]","category":"5524f5bcd919032b0057ac36","createdAt":"2015-04-16T16:51:59.282Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":1,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"success-url-api","sync_unique":"","title":"Success URL","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Success URL


Upon a successful transaction being completed, ImpulsePay will forward the consumer to the Success URL specified by the merchant in the Config dashboard. The MSISDN and Timestamp parameters are encrypted using a 24 character, Base64 Encryption Key specified by the merchant on the Settings/Create RouteID page on the Dashboard. Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. The following parameters are also passed through to the merchant: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Data type", "0-0": "PWID", "1-0": "CampaignID", "2-0": "Operator", "3-0": "Status", "4-0": "Note", "5-0": "AffiliateID", "6-0": "FriendlyName", "7-0": "Timestamp", "0-1": "ImpulsePay's unique identifier for the consumers purchase", "4-1": "Custom parameters passed through from the initial interaction with the payment page", "5-1": "Affiliate values passed through from the initial interaction with the payment page", "6-1": "The value specified in the payment button to help identify the service", "7-1": "The time when the purchase was made. If in the last 5 minutes, the access can be seen as valid. Encrypted using the Encryption Key specified on the Settings page.", "2-1": "The mobile network operator for the consumer.", "3-1": "The short status code for the status of the payment.", "1-1": "The merchant's identifier for the campaign", "0-2": "String - 75 characters", "1-2": "String - 15 characters", "2-2": "o2_uk,\norange_uk,\nthree_uk,\ntmobile_uk,\nvirgin_uk,\nvodafone_uk,", "3-2": "Int", "4-2": "String - 250 characters", "5-2": "String - 250 characters", "6-2": "String - 30 characters", "7-2": "YYYY-MM-DD HH:MM:SS", "8-0": "Tariff", "8-1": "The tariff (in pence) that the consumer has purchased.", "8-2": "Int", "9-0": "MSISDN", "10-0": "MSISDNType", "9-1": "The MSISDN or Alias for the consumer. This parameter is encoded using the Encryption Key specified on the Settings page.", "10-1": "Flag to specify if this is a MSISDN or ALIAS being passed.", "9-2": "Int", "10-2": "ALIAS\nMSISDN" }, "cols": 3, "rows": 11 } [/block]
Upon a successful transaction being completed, ImpulsePay will forward the consumer to the Success URL specified by the merchant in the Config dashboard. The MSISDN and Timestamp parameters are encrypted using a 24 character, Base64 Encryption Key specified by the merchant on the Settings/Create RouteID page on the Dashboard. Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. The following parameters are also passed through to the merchant: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Data type", "0-0": "PWID", "1-0": "CampaignID", "2-0": "Operator", "3-0": "Status", "4-0": "Note", "5-0": "AffiliateID", "6-0": "FriendlyName", "7-0": "Timestamp", "0-1": "ImpulsePay's unique identifier for the consumers purchase", "4-1": "Custom parameters passed through from the initial interaction with the payment page", "5-1": "Affiliate values passed through from the initial interaction with the payment page", "6-1": "The value specified in the payment button to help identify the service", "7-1": "The time when the purchase was made. If in the last 5 minutes, the access can be seen as valid. Encrypted using the Encryption Key specified on the Settings page.", "2-1": "The mobile network operator for the consumer.", "3-1": "The short status code for the status of the payment.", "1-1": "The merchant's identifier for the campaign", "0-2": "String - 75 characters", "1-2": "String - 15 characters", "2-2": "o2_uk,\norange_uk,\nthree_uk,\ntmobile_uk,\nvirgin_uk,\nvodafone_uk,", "3-2": "Int", "4-2": "String - 250 characters", "5-2": "String - 250 characters", "6-2": "String - 30 characters", "7-2": "YYYY-MM-DD HH:MM:SS", "8-0": "Tariff", "8-1": "The tariff (in pence) that the consumer has purchased.", "8-2": "Int", "9-0": "MSISDN", "10-0": "MSISDNType", "9-1": "The MSISDN or Alias for the consumer. This parameter is encoded using the Encryption Key specified on the Settings page.", "10-1": "Flag to specify if this is a MSISDN or ALIAS being passed.", "9-2": "Int", "10-2": "ALIAS\nMSISDN" }, "cols": 3, "rows": 11 } [/block]
{"__v":4,"_id":"552fea2a633a5b0d00e99e5f","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"If a transaction fails, ImpulsePay will forward the consumer to the Failure URL specified by the merchant in the Config dashboard. \n\nMerchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.\n\nThe following parameters are also passed through the merchant: \n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Data type\",\n    \"0-0\": \"PWID\",\n    \"1-0\": \"CampaignID\",\n    \"2-0\": \"Operator\",\n    \"3-0\": \"Status\",\n    \"4-0\": \"Note\",\n    \"5-0\": \"AffiliateID\",\n    \"6-0\": \"FriendlyName\",\n    \"0-1\": \"ImpulsePay's unique identifier for the consumers purchase\",\n    \"4-1\": \"Custom parameters passed through from the initial interaction with the payment page\",\n    \"5-1\": \"Affiliate values passed through from the initial interaction with the payment page\",\n    \"6-1\": \"The value specified in the payment button to help identify the service\",\n    \"2-1\": \"The mobile network operator for the consumer.\",\n    \"3-1\": \"The short status code for the status of the payment.\",\n    \"1-1\": \"The merchant's identifier for the campaign\",\n    \"0-2\": \"String - 75 characters\",\n    \"1-2\": \"String - 15 characters\",\n    \"2-2\": \"o2_uk, \\norange_uk,\\nthree_uk, \\ntmobile_uk, \\nvirgin_uk, \\nvodafone_uk,\",\n    \"3-2\": \"Int\",\n    \"4-2\": \"String - 250 characters\",\n    \"5-2\": \"String - 250 characters\",\n    \"6-2\": \"String - 30 characters\"\n  },\n  \"cols\": 3,\n  \"rows\": 7\n}\n[/block]","category":"5524f5bcd919032b0057ac36","createdAt":"2015-04-16T16:58:18.791Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":2,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"failure-url-api","sync_unique":"","title":"Failure URL","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Failure URL


If a transaction fails, ImpulsePay will forward the consumer to the Failure URL specified by the merchant in the Config dashboard. Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. The following parameters are also passed through the merchant: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Data type", "0-0": "PWID", "1-0": "CampaignID", "2-0": "Operator", "3-0": "Status", "4-0": "Note", "5-0": "AffiliateID", "6-0": "FriendlyName", "0-1": "ImpulsePay's unique identifier for the consumers purchase", "4-1": "Custom parameters passed through from the initial interaction with the payment page", "5-1": "Affiliate values passed through from the initial interaction with the payment page", "6-1": "The value specified in the payment button to help identify the service", "2-1": "The mobile network operator for the consumer.", "3-1": "The short status code for the status of the payment.", "1-1": "The merchant's identifier for the campaign", "0-2": "String - 75 characters", "1-2": "String - 15 characters", "2-2": "o2_uk, \norange_uk,\nthree_uk, \ntmobile_uk, \nvirgin_uk, \nvodafone_uk,", "3-2": "Int", "4-2": "String - 250 characters", "5-2": "String - 250 characters", "6-2": "String - 30 characters" }, "cols": 3, "rows": 7 } [/block]
If a transaction fails, ImpulsePay will forward the consumer to the Failure URL specified by the merchant in the Config dashboard. Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. The following parameters are also passed through the merchant: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Data type", "0-0": "PWID", "1-0": "CampaignID", "2-0": "Operator", "3-0": "Status", "4-0": "Note", "5-0": "AffiliateID", "6-0": "FriendlyName", "0-1": "ImpulsePay's unique identifier for the consumers purchase", "4-1": "Custom parameters passed through from the initial interaction with the payment page", "5-1": "Affiliate values passed through from the initial interaction with the payment page", "6-1": "The value specified in the payment button to help identify the service", "2-1": "The mobile network operator for the consumer.", "3-1": "The short status code for the status of the payment.", "1-1": "The merchant's identifier for the campaign", "0-2": "String - 75 characters", "1-2": "String - 15 characters", "2-2": "o2_uk, \norange_uk,\nthree_uk, \ntmobile_uk, \nvirgin_uk, \nvodafone_uk,", "3-2": "Int", "4-2": "String - 250 characters", "5-2": "String - 250 characters", "6-2": "String - 30 characters" }, "cols": 3, "rows": 7 } [/block]
{"__v":8,"_id":"553e05b68feab90d0059d742","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"It is possible for merchants to use dynamic content on their payment page, allowing small changes and alterations to be made to pre-agreed page elements such as text areas, tracking code and headings. \n\nThe feature makes use of two copies of the payment page; the live version hosted by ImpulsePay and a copy hosted by the merchant. Dynamic content areas are tagged on the live version, with ImpulsePay requesting the merchant's copy to check if any changes to the dynamic content areas have been made. \n\nFor a merchant to use the dynamic content feature, they must pre-agree with ImpulsePay the areas which they wish to make dynamic. The changeable areas most likely to be permitted will be text areas, tracking code and page headings. Dynamic changes relating to the key terms surrounding the purchase are likely to be rejected. \n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Setting up\"\n}\n[/block]\nAfter agreeing dynamic content areas with ImpulsePay, the merchant can enable dynamic content by adding the following elements to their payment page. \n\nTo begin setup, a copy of the merchant's payment page needs to be uploaded into the Editor, along with any additional images and submitted for approval. \n\nDynamic content areas on the payment page need to be placed within <dynamic> tags, along with a unique ID (0 - 9, A - Z), as shown below: \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<dynamic data-id=\\\"ABC123\\\">This is dynamic content</dynamic>\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\nThe merchant then needs to add a 'SourceURL' parameter into the Editor. This is the URL that ImpulsePay will request to collect the dynamic content hosted by the merchant on their copy of the payment page. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Page load\"\n}\n[/block]\n\nWhen the payment page is loaded, a call is made to the SourceURL entered into the Config page. \n\nMerchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.\n\nThe following parameters are then passed to the merchant:\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"PWID\",\n    \"1-0\": \"CampaignID\",\n    \"2-0\": \"Note\",\n    \"3-0\": \"AffiliateID\",\n    \"0-1\": \"A 75 character unique ID for this transaction.\",\n    \"1-1\": \"The CampaignID specified for this request.\",\n    \"2-1\": \"Merchant specific parameters.\",\n    \"3-1\": \"Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.\",\n    \"0-2\": \"201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8\",\n    \"1-2\": \"ABC123\",\n    \"2-2\": \"Param1#Param2#Param3\",\n    \"3-2\": \"A=1;B=2\",\n    \"4-2\": \"754YUCSJO-D09EE0E7-AB97-4A21-9T50-AB62967D0F54FFC412136342A3\",\n    \"4-1\": \"Unique 60 character ID displayed to the consumer\",\n    \"4-0\": \"TemplateID\"\n  },\n  \"cols\": 3,\n  \"rows\": 5\n}\n[/block]\nEach <dynamic> section on the payment page is then replaced with the corresponding section from the SourceURL's response, by matching the data-id within the tags. \n\nIn the case an error where the dynamic tag is not found, then the dynamic section will be ignored and the rest of the payment page is returned to the consumer.","category":"5524f5bcd919032b0057ac36","createdAt":"2015-04-27T09:47:34.807Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":3,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"dynamic-content","sync_unique":"","title":"Dynamic Content","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Dynamic Content


It is possible for merchants to use dynamic content on their payment page, allowing small changes and alterations to be made to pre-agreed page elements such as text areas, tracking code and headings. The feature makes use of two copies of the payment page; the live version hosted by ImpulsePay and a copy hosted by the merchant. Dynamic content areas are tagged on the live version, with ImpulsePay requesting the merchant's copy to check if any changes to the dynamic content areas have been made. For a merchant to use the dynamic content feature, they must pre-agree with ImpulsePay the areas which they wish to make dynamic. The changeable areas most likely to be permitted will be text areas, tracking code and page headings. Dynamic changes relating to the key terms surrounding the purchase are likely to be rejected. [block:api-header] { "type": "basic", "title": "Setting up" } [/block] After agreeing dynamic content areas with ImpulsePay, the merchant can enable dynamic content by adding the following elements to their payment page. To begin setup, a copy of the merchant's payment page needs to be uploaded into the Editor, along with any additional images and submitted for approval. Dynamic content areas on the payment page need to be placed within <dynamic> tags, along with a unique ID (0 - 9, A - Z), as shown below: [block:code] { "codes": [ { "code": "<dynamic data-id=\"ABC123\">This is dynamic content</dynamic>", "language": "text" } ] } [/block] The merchant then needs to add a 'SourceURL' parameter into the Editor. This is the URL that ImpulsePay will request to collect the dynamic content hosted by the merchant on their copy of the payment page. [block:api-header] { "type": "basic", "title": "Page load" } [/block] When the payment page is loaded, a call is made to the SourceURL entered into the Config page. Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. The following parameters are then passed to the merchant: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "PWID", "1-0": "CampaignID", "2-0": "Note", "3-0": "AffiliateID", "0-1": "A 75 character unique ID for this transaction.", "1-1": "The CampaignID specified for this request.", "2-1": "Merchant specific parameters.", "3-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-2": "ABC123", "2-2": "Param1#Param2#Param3", "3-2": "A=1;B=2", "4-2": "754YUCSJO-D09EE0E7-AB97-4A21-9T50-AB62967D0F54FFC412136342A3", "4-1": "Unique 60 character ID displayed to the consumer", "4-0": "TemplateID" }, "cols": 3, "rows": 5 } [/block] Each <dynamic> section on the payment page is then replaced with the corresponding section from the SourceURL's response, by matching the data-id within the tags. In the case an error where the dynamic tag is not found, then the dynamic section will be ignored and the rest of the payment page is returned to the consumer.
It is possible for merchants to use dynamic content on their payment page, allowing small changes and alterations to be made to pre-agreed page elements such as text areas, tracking code and headings. The feature makes use of two copies of the payment page; the live version hosted by ImpulsePay and a copy hosted by the merchant. Dynamic content areas are tagged on the live version, with ImpulsePay requesting the merchant's copy to check if any changes to the dynamic content areas have been made. For a merchant to use the dynamic content feature, they must pre-agree with ImpulsePay the areas which they wish to make dynamic. The changeable areas most likely to be permitted will be text areas, tracking code and page headings. Dynamic changes relating to the key terms surrounding the purchase are likely to be rejected. [block:api-header] { "type": "basic", "title": "Setting up" } [/block] After agreeing dynamic content areas with ImpulsePay, the merchant can enable dynamic content by adding the following elements to their payment page. To begin setup, a copy of the merchant's payment page needs to be uploaded into the Editor, along with any additional images and submitted for approval. Dynamic content areas on the payment page need to be placed within <dynamic> tags, along with a unique ID (0 - 9, A - Z), as shown below: [block:code] { "codes": [ { "code": "<dynamic data-id=\"ABC123\">This is dynamic content</dynamic>", "language": "text" } ] } [/block] The merchant then needs to add a 'SourceURL' parameter into the Editor. This is the URL that ImpulsePay will request to collect the dynamic content hosted by the merchant on their copy of the payment page. [block:api-header] { "type": "basic", "title": "Page load" } [/block] When the payment page is loaded, a call is made to the SourceURL entered into the Config page. Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. The following parameters are then passed to the merchant: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "PWID", "1-0": "CampaignID", "2-0": "Note", "3-0": "AffiliateID", "0-1": "A 75 character unique ID for this transaction.", "1-1": "The CampaignID specified for this request.", "2-1": "Merchant specific parameters.", "3-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-2": "ABC123", "2-2": "Param1#Param2#Param3", "3-2": "A=1;B=2", "4-2": "754YUCSJO-D09EE0E7-AB97-4A21-9T50-AB62967D0F54FFC412136342A3", "4-1": "Unique 60 character ID displayed to the consumer", "4-0": "TemplateID" }, "cols": 3, "rows": 5 } [/block] Each <dynamic> section on the payment page is then replaced with the corresponding section from the SourceURL's response, by matching the data-id within the tags. In the case an error where the dynamic tag is not found, then the dynamic section will be ignored and the rest of the payment page is returned to the consumer.
{"__v":4,"_id":"556c5aa875996f2d00c2b35e","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"Testmode provides a development environment that allows merchants to test their Payment Page integration end to end. Using Testmode, Payment Pages are fully functional but are not live to the public. \n\nTestmode is not required if merchants are wish testing how the design of a Payment Page renders when loaded in the browser. The Preview Link button on the Payment Page editor can be used to achieve this, without using Testmode. \n[block:callout]\n{\n  \"type\": \"danger\",\n  \"body\": \"Only production-ready Payment Pages should be submitted for approval in the Editor. In all other cases, Testmode should be used.\",\n  \"title\": \"Payment Page Approval\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Implementing Testmode\"\n}\n[/block]\nBefore using Testmode, Testmode tokens can be obtained on the Account Details page on the Dashboard. There are two individual tokens for each network, providing either a MSISDNalias and a MSISDN for the test transaction. \n\nTestmode is enabled by adding additional parameters to the [Service URL](doc:inbound-service-url).\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Param\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"TemplateID\",\n    \"1-0\": \"TestMode\",\n    \"0-1\": \"The TemplateID for the template to use for this request. If a page has not been approved, Testmode parameter must be specified for the page to be viewed.\",\n    \"1-1\": \"This is the token provided by ImpulsePay on the My Account page which allows Merchants to test services in a development environment. There are tokens available for each individual networks for MNO specific tests.\",\n    \"2-0\": \"TestFail\",\n    \"2-1\": \"This will force a transaction to fail when set to Y and used in conjunction with TestMode.\",\n    \"3-0\": \"\",\n    \"2-2\": \"\\\"Y\\\"\",\n    \"1-2\": \"\\\"\\\"\"\n  },\n  \"cols\": 2,\n  \"rows\": 3\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Testmode MSISDNs and MSISDNalias\"\n}\n[/block]\nThe testmode tokens found on the Account Details page should resolve to the following numbers during testing. \n\nAlias tokens will resolve to a number starting 4470.\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Token Name\",\n    \"h-1\": \"Resolved MSISDN/MSISDNalias\",\n    \"h-2\": \"Resolved\",\n    \"0-0\": \"O2 MSISDN\",\n    \"1-0\": \"Orange MSISDN\",\n    \"2-0\": \"Three MSISDN\",\n    \"3-0\": \"T-Mobile and EE MSISDN\",\n    \"4-0\": \"Vodafone MSISDN\",\n    \"0-1\": \"447700900002\",\n    \"1-1\": \"447700900004\",\n    \"2-1\": \"447700900008\",\n    \"3-1\": \"447700900016\",\n    \"4-1\": \"447700900064\"\n  },\n  \"cols\": 2,\n  \"rows\": 5\n}\n[/block]","category":"5524f5bcd919032b0057ac36","createdAt":"2015-06-01T13:14:16.682Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":4,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"using-testmode","sync_unique":"","title":"Using Testmode","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Using Testmode


Testmode provides a development environment that allows merchants to test their Payment Page integration end to end. Using Testmode, Payment Pages are fully functional but are not live to the public. Testmode is not required if merchants are wish testing how the design of a Payment Page renders when loaded in the browser. The Preview Link button on the Payment Page editor can be used to achieve this, without using Testmode. [block:callout] { "type": "danger", "body": "Only production-ready Payment Pages should be submitted for approval in the Editor. In all other cases, Testmode should be used.", "title": "Payment Page Approval" } [/block] [block:api-header] { "type": "basic", "title": "Implementing Testmode" } [/block] Before using Testmode, Testmode tokens can be obtained on the Account Details page on the Dashboard. There are two individual tokens for each network, providing either a MSISDNalias and a MSISDN for the test transaction. Testmode is enabled by adding additional parameters to the [Service URL](doc:inbound-service-url). [block:parameters] { "data": { "h-0": "Param", "h-1": "Description", "h-2": "Example", "0-0": "TemplateID", "1-0": "TestMode", "0-1": "The TemplateID for the template to use for this request. If a page has not been approved, Testmode parameter must be specified for the page to be viewed.", "1-1": "This is the token provided by ImpulsePay on the My Account page which allows Merchants to test services in a development environment. There are tokens available for each individual networks for MNO specific tests.", "2-0": "TestFail", "2-1": "This will force a transaction to fail when set to Y and used in conjunction with TestMode.", "3-0": "", "2-2": "\"Y\"", "1-2": "\"\"" }, "cols": 2, "rows": 3 } [/block] [block:api-header] { "type": "basic", "title": "Testmode MSISDNs and MSISDNalias" } [/block] The testmode tokens found on the Account Details page should resolve to the following numbers during testing. Alias tokens will resolve to a number starting 4470. [block:parameters] { "data": { "h-0": "Token Name", "h-1": "Resolved MSISDN/MSISDNalias", "h-2": "Resolved", "0-0": "O2 MSISDN", "1-0": "Orange MSISDN", "2-0": "Three MSISDN", "3-0": "T-Mobile and EE MSISDN", "4-0": "Vodafone MSISDN", "0-1": "447700900002", "1-1": "447700900004", "2-1": "447700900008", "3-1": "447700900016", "4-1": "447700900064" }, "cols": 2, "rows": 5 } [/block]
Testmode provides a development environment that allows merchants to test their Payment Page integration end to end. Using Testmode, Payment Pages are fully functional but are not live to the public. Testmode is not required if merchants are wish testing how the design of a Payment Page renders when loaded in the browser. The Preview Link button on the Payment Page editor can be used to achieve this, without using Testmode. [block:callout] { "type": "danger", "body": "Only production-ready Payment Pages should be submitted for approval in the Editor. In all other cases, Testmode should be used.", "title": "Payment Page Approval" } [/block] [block:api-header] { "type": "basic", "title": "Implementing Testmode" } [/block] Before using Testmode, Testmode tokens can be obtained on the Account Details page on the Dashboard. There are two individual tokens for each network, providing either a MSISDNalias and a MSISDN for the test transaction. Testmode is enabled by adding additional parameters to the [Service URL](doc:inbound-service-url). [block:parameters] { "data": { "h-0": "Param", "h-1": "Description", "h-2": "Example", "0-0": "TemplateID", "1-0": "TestMode", "0-1": "The TemplateID for the template to use for this request. If a page has not been approved, Testmode parameter must be specified for the page to be viewed.", "1-1": "This is the token provided by ImpulsePay on the My Account page which allows Merchants to test services in a development environment. There are tokens available for each individual networks for MNO specific tests.", "2-0": "TestFail", "2-1": "This will force a transaction to fail when set to Y and used in conjunction with TestMode.", "3-0": "", "2-2": "\"Y\"", "1-2": "\"\"" }, "cols": 2, "rows": 3 } [/block] [block:api-header] { "type": "basic", "title": "Testmode MSISDNs and MSISDNalias" } [/block] The testmode tokens found on the Account Details page should resolve to the following numbers during testing. Alias tokens will resolve to a number starting 4470. [block:parameters] { "data": { "h-0": "Token Name", "h-1": "Resolved MSISDN/MSISDNalias", "h-2": "Resolved", "0-0": "O2 MSISDN", "1-0": "Orange MSISDN", "2-0": "Three MSISDN", "3-0": "T-Mobile and EE MSISDN", "4-0": "Vodafone MSISDN", "0-1": "447700900002", "1-1": "447700900004", "2-1": "447700900008", "3-1": "447700900016", "4-1": "447700900064" }, "cols": 2, "rows": 5 } [/block]
{"__v":8,"_id":"568d2e1963fefd0d00d0694c","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"A confirmation page, otherwise known as a payment acknowledgement screen, can be added to the Editor and enabled on a per-network basis for individual services. The confirmation page is shown once a consumer has made a purchase, with a continue button loaded onto the page by ImpulsePay to allow the consumer to access the Success URL. An optional 5 second auto-redirect can also be added which means the consumer is not required to click the continue button. \n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/G1WODsXRM6dry2R46mmL_confpage.png\",\n        \"confpage.png\",\n        \"976\",\n        \"566\",\n        \"#094c66\",\n        \"\"\n      ],\n      \"sizing\": \"80\"\n    }\n  ]\n}\n[/block]\nMerchants may use a generic confirmation page or design confirmation pages for individual services. Pages should be created in the Editor and then submitted for approval. Note that confirmation pages are only checked internally by ImpulsePay and do not go through the usual approval process.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Building the confirmation page\"\n}\n[/block]\nMerchants should use the Editor to build a confirmation page as they would a normal payment page. Each confirmation page will have a continue button loaded into the page by ImpulsePay, so the following HTML code for the continue button must be added to the confirmation page, in a similar style to the purchase button HTML code for payment pages. The colour of the button and text on the button can be set to whatever the merchant requires. \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<button type=\\\"confirmation\\\" \\n data-ctatext=“Continue\\\"\\n data-cnColour=\\\"FFFFFF\\\"\\n data-buttonBorder=\\\"FFFFFF\\\"\\n data-buttoncolour=“25753D\\\"\\n</button>\\n\",\n      \"language\": \"html\",\n      \"name\": \"Confirmation Continue Button\"\n    }\n  ]\n}\n[/block]\nThe following parameters can be added as optional button attributes:\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Attribute\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"data-autoredirect=\\\"Y\\\"\",\n    \"0-1\": \"Include this attribute to enable a 5 second auto-redirect from the Confirmation page to the SuccessURL\",\n    \"0-2\": \"\",\n    \"2-0\": \"data-cnColour\",\n    \"2-1\": \"A hex code for the colour of the charge notification text.\",\n    \"2-2\": \"FFFFFF\",\n    \"3-0\": \"data-buttoncolour\",\n    \"3-1\": \"A hex code for the base colour of the button.\",\n    \"3-2\": \"03394A\",\n    \"4-0\": \"data-buttongradient\",\n    \"4-1\": \"A hex code for the gradient contrast of the button.\",\n    \"4-2\": \"05658A\",\n    \"5-0\": \"data-buttonBorder\",\n    \"5-1\": \"A hex code for the colour of the button border.\",\n    \"5-2\": \"000000\",\n    \"6-0\": \"data-ctatext\",\n    \"6-1\": \"Text to use inside the button.\",\n    \"6-2\": \"Continue\",\n    \"1-0\": \"data-edgeSize\",\n    \"1-1\": \"The size of the edge of the button border, in pixels.\",\n    \"1-2\": \"8\"\n  },\n  \"cols\": 3,\n  \"rows\": 7\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Approval and enabling confirmation page\"\n}\n[/block]\nOnce a confirmation page is approved, it can be enabled on the Payment Page Configurator panel on the Route Settings page.  There is a confirmation page dropdown available for each device type, and also each network. Approved confirmation pages will appear in the dropdown.","category":"5524f5bcd919032b0057ac36","createdAt":"2016-01-06T15:09:13.473Z","excerpt":"How to create deploy and manage a confirmation page","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":5,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"confirmation-page","sync_unique":"","title":"Confirmation page","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Confirmation page

How to create deploy and manage a confirmation page

A confirmation page, otherwise known as a payment acknowledgement screen, can be added to the Editor and enabled on a per-network basis for individual services. The confirmation page is shown once a consumer has made a purchase, with a continue button loaded onto the page by ImpulsePay to allow the consumer to access the Success URL. An optional 5 second auto-redirect can also be added which means the consumer is not required to click the continue button. [block:image] { "images": [ { "image": [ "https://files.readme.io/G1WODsXRM6dry2R46mmL_confpage.png", "confpage.png", "976", "566", "#094c66", "" ], "sizing": "80" } ] } [/block] Merchants may use a generic confirmation page or design confirmation pages for individual services. Pages should be created in the Editor and then submitted for approval. Note that confirmation pages are only checked internally by ImpulsePay and do not go through the usual approval process. [block:api-header] { "type": "basic", "title": "Building the confirmation page" } [/block] Merchants should use the Editor to build a confirmation page as they would a normal payment page. Each confirmation page will have a continue button loaded into the page by ImpulsePay, so the following HTML code for the continue button must be added to the confirmation page, in a similar style to the purchase button HTML code for payment pages. The colour of the button and text on the button can be set to whatever the merchant requires. [block:code] { "codes": [ { "code": "<button type=\"confirmation\" \n data-ctatext=“Continue\"\n data-cnColour=\"FFFFFF\"\n data-buttonBorder=\"FFFFFF\"\n data-buttoncolour=“25753D\"\n</button>\n", "language": "html", "name": "Confirmation Continue Button" } ] } [/block] The following parameters can be added as optional button attributes: [block:parameters] { "data": { "h-0": "Attribute", "h-1": "Description", "h-2": "Example", "0-0": "data-autoredirect=\"Y\"", "0-1": "Include this attribute to enable a 5 second auto-redirect from the Confirmation page to the SuccessURL", "0-2": "", "2-0": "data-cnColour", "2-1": "A hex code for the colour of the charge notification text.", "2-2": "FFFFFF", "3-0": "data-buttoncolour", "3-1": "A hex code for the base colour of the button.", "3-2": "03394A", "4-0": "data-buttongradient", "4-1": "A hex code for the gradient contrast of the button.", "4-2": "05658A", "5-0": "data-buttonBorder", "5-1": "A hex code for the colour of the button border.", "5-2": "000000", "6-0": "data-ctatext", "6-1": "Text to use inside the button.", "6-2": "Continue", "1-0": "data-edgeSize", "1-1": "The size of the edge of the button border, in pixels.", "1-2": "8" }, "cols": 3, "rows": 7 } [/block] [block:api-header] { "type": "basic", "title": "Approval and enabling confirmation page" } [/block] Once a confirmation page is approved, it can be enabled on the Payment Page Configurator panel on the Route Settings page. There is a confirmation page dropdown available for each device type, and also each network. Approved confirmation pages will appear in the dropdown.
A confirmation page, otherwise known as a payment acknowledgement screen, can be added to the Editor and enabled on a per-network basis for individual services. The confirmation page is shown once a consumer has made a purchase, with a continue button loaded onto the page by ImpulsePay to allow the consumer to access the Success URL. An optional 5 second auto-redirect can also be added which means the consumer is not required to click the continue button. [block:image] { "images": [ { "image": [ "https://files.readme.io/G1WODsXRM6dry2R46mmL_confpage.png", "confpage.png", "976", "566", "#094c66", "" ], "sizing": "80" } ] } [/block] Merchants may use a generic confirmation page or design confirmation pages for individual services. Pages should be created in the Editor and then submitted for approval. Note that confirmation pages are only checked internally by ImpulsePay and do not go through the usual approval process. [block:api-header] { "type": "basic", "title": "Building the confirmation page" } [/block] Merchants should use the Editor to build a confirmation page as they would a normal payment page. Each confirmation page will have a continue button loaded into the page by ImpulsePay, so the following HTML code for the continue button must be added to the confirmation page, in a similar style to the purchase button HTML code for payment pages. The colour of the button and text on the button can be set to whatever the merchant requires. [block:code] { "codes": [ { "code": "<button type=\"confirmation\" \n data-ctatext=“Continue\"\n data-cnColour=\"FFFFFF\"\n data-buttonBorder=\"FFFFFF\"\n data-buttoncolour=“25753D\"\n</button>\n", "language": "html", "name": "Confirmation Continue Button" } ] } [/block] The following parameters can be added as optional button attributes: [block:parameters] { "data": { "h-0": "Attribute", "h-1": "Description", "h-2": "Example", "0-0": "data-autoredirect=\"Y\"", "0-1": "Include this attribute to enable a 5 second auto-redirect from the Confirmation page to the SuccessURL", "0-2": "", "2-0": "data-cnColour", "2-1": "A hex code for the colour of the charge notification text.", "2-2": "FFFFFF", "3-0": "data-buttoncolour", "3-1": "A hex code for the base colour of the button.", "3-2": "03394A", "4-0": "data-buttongradient", "4-1": "A hex code for the gradient contrast of the button.", "4-2": "05658A", "5-0": "data-buttonBorder", "5-1": "A hex code for the colour of the button border.", "5-2": "000000", "6-0": "data-ctatext", "6-1": "Text to use inside the button.", "6-2": "Continue", "1-0": "data-edgeSize", "1-1": "The size of the edge of the button border, in pixels.", "1-2": "8" }, "cols": 3, "rows": 7 } [/block] [block:api-header] { "type": "basic", "title": "Approval and enabling confirmation page" } [/block] Once a confirmation page is approved, it can be enabled on the Payment Page Configurator panel on the Route Settings page. There is a confirmation page dropdown available for each device type, and also each network. Approved confirmation pages will appear in the dropdown.
{"__v":35,"_id":"5524f5bdd919032b0057ac3d","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"Payment alerts are sent in real time, as a payment is being processed. For services using recurring payments, these alerts are sent once a payment has been processed. Billing notifications are made to a merchant using an HTTP(s) GET in real time. \n\nThe URL should be updated using the Config page on the Dashboard and once configured, the following parameters are passed on each request. \n\nNotifications are sent before the consumer is redirected to the Success or Failure URL. In the case of a notification failing to be delivered, it will be retried according to the notification retry policy and the consumer will be forwarded to the success or failure URL. \n\nMerchants can append their own static parameters to the Notification URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"3-0\": \"CampaignID\",\n    \"4-0\": \"Tariff\",\n    \"5-0\": \"Operator\",\n    \"6-0\": \"Status\",\n    \"7-0\": \"ExtendedStatus\",\n    \"8-0\": \"Billed\",\n    \"9-0\": \"ScreenshotURL\",\n    \"10-0\": \"FlowMethod\",\n    \"11-0\": \"FlowType\",\n    \"12-0\": \"Note\",\n    \"13-0\": \"AffiliateID\",\n    \"14-0\": \"Useragent\",\n    \"15-0\": \"URLReferer\",\n    \"16-0\": \"FriendlyName\",\n    \"17-0\": \"AccessURL\",\n    \"3-1\": \"The CampaignID specified for this request.\",\n    \"4-1\": \"The tariff (in pence) that the consumer was purchased.\",\n    \"5-1\": \"The consumers mobile operator.\",\n    \"6-1\": \"Status code for this transaction.\",\n    \"7-1\": \"The extended status code for this transaction.\",\n    \"8-1\": \"Timestamp of the transaction.\",\n    \"9-1\": \"URL to the screenshot taken for this transaction.\",\n    \"10-1\": \"The device type used for this transaction.\",\n    \"11-1\": \"The verification method that was used for the payment.\",\n    \"12-1\": \"The merchant can use the note for passing custom parameters through. These will be returned to the merchant in the billing notification. This can be a maximum of 250 characters.\",\n    \"13-1\": \"Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.\",\n    \"14-1\": \"The user agent type for which the transaction was processed for.\",\n    \"15-1\": \"URL referrer, SMS message text used to access service by (when known).\",\n    \"16-1\": \"FriendlyName that was passed in through the button on the Paywall engine.\",\n    \"17-1\": \"URL used to access the site by the consumer.\",\n    \"3-2\": \"ABC123\",\n    \"4-2\": \"450 for £4.50\",\n    \"5-2\": \"o2_uk,\\norange_uk,\\nthree_uk,\\ntmobile_uk,\\nvirgin_uk,\\nvodafone_uk\",\n    \"6-2\": \"100\",\n    \"7-2\": \"See 'Operator Status codes' section\",\n    \"8-2\": \"YYYY-MM-DD HH:HH:SS\",\n    \"9-2\": \"http://html.impulsepay.com/{ID}.html\",\n    \"10-2\": \"Desktop\\nMobile\\niPad\\niPhone\\nAndroid\",\n    \"11-2\": \"**SMS** - SMS marketing message link used\\n**MobileData** - 3G/ 4G data verification\\n**MT Link **- Consumer entered MSISDN\\n**IVR Call** - Consumer called IVR line\\n**MO Msg** - Consumer texted keyword\\n**Repeat **- Recurring payment\",\n    \"12-2\": \"Param1#Param2#Param3\",\n    \"13-2\": \"A=1;B=2\",\n    \"14-2\": \"Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10.\",\n    \"16-2\": \"Access24Hrs3\",\n    \"15-2\": \"Http://www.google.com\",\n    \"17-2\": \"http://m.merchantsite.com/1000/ABC123\",\n    \"0-0\": \"MSISDN\",\n    \"1-0\": \"MSISDNType\",\n    \"0-1\": \"The MSISDN or Alias for the consumer.\",\n    \"1-1\": \"Flag to specify if this is a MSISDN or ALIAS being passed.\",\n    \"0-2\": \"447123123123\",\n    \"1-2\": \"MSISDN | ALIAS\",\n    \"2-0\": \"PWID\",\n    \"2-1\": \"A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.\",\n    \"2-2\": \"201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8\",\n    \"18-0\": \"TemplateID\",\n    \"19-0\": \"TemplateName\",\n    \"20-0\": \"AccountID\",\n    \"21-0\": \"RouteID\",\n    \"18-1\": \"The unique ID for the payment page used for the payment.\",\n    \"19-1\": \"The name given to the template by the merchant.\",\n    \"20-1\": \"The merchants AccountID.\",\n    \"21-1\": \"The RouteID used for the purchase.\",\n    \"20-2\": \"112900\",\n    \"21-2\": \"1000123\",\n    \"19-2\": \"YourTemplate\",\n    \"18-2\": \"ABC-123\"\n  },\n  \"cols\": 3,\n  \"rows\": 22\n}\n[/block]\nAdditional parameters for Repeat billing notifications will be sent once the first recurring payment is made. Only the RPID will be sent after the initial charge and creation of the recurring payment. Please note that when using Testmode, the RPID and additional parameters will not be delivered, as no Recurring Payment is established. You may use the RPID example below to simulate the RPID inclusion in Notify Billing. \n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameters\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"RPID\",\n    \"0-1\": \"Unique ID to identify this recurring payment subscription that stays persistent across all notifications for this subscription.\",\n    \"0-2\": \"201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8\",\n    \"1-0\": \"TimesBilled\",\n    \"1-1\": \"Number of times the MSISDN has been billed in this recurring payment cycle.\",\n    \"1-2\": \"4\",\n    \"2-0\": \"LastReceiptSent\",\n    \"2-1\": \"The date the last reminder text was sent for either £20 spend or 30 day reminder.\",\n    \"3-0\": \"NextCharge\",\n    \"3-1\": \"The date for when the next charge is scheduled to be made, if not cancelled by the user.\",\n    \"3-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"4-0\": \"BillingPeriod\",\n    \"4-1\": \"Period of the recurring charges.\",\n    \"4-2\": \"WEEK\\nMONTH\",\n    \"5-0\": \"Frequency\",\n    \"5-1\": \"Frequency of the recurring charges.\",\n    \"5-2\": \"7\",\n    \"6-0\": \"CreatedAt\",\n    \"6-1\": \"Date that the user opted into the recurring payment.\",\n    \"7-0\": \"LastInteraction\",\n    \"7-1\": \"The last time the service was used (this is used to define the starting point of the 120 day inactivity rule).\",\n    \"2-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"6-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"7-2\": \"YYYY-MM-DD HH:MM:SS\"\n  },\n  \"cols\": 3,\n  \"rows\": 8\n}\n[/block]\nBillingStatus will consist of these codes:\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Status Code\",\n    \"h-1\": \"Meaning\",\n    \"0-0\": \"100\",\n    \"1-0\": \"140\",\n    \"0-1\": \"Billed\",\n    \"1-1\": \"In Progress\",\n    \"5-0\": \"200\",\n    \"5-1\": \"Failed\",\n    \"6-0\": \"201\",\n    \"6-1\": \"Failed\",\n    \"7-0\": \"202\",\n    \"7-1\": \"Failed\",\n    \"8-0\": \"203\",\n    \"8-1\": \"Failed\",\n    \"9-0\": \"204\",\n    \"9-1\": \"Failed\",\n    \"h-2\": \"Description\",\n    \"0-2\": \"Billed Successfully.\",\n    \"1-2\": \"Attempting to bill. Status should update to a 100 or 20x range code shortly. This status code may be shown on the dashboard but will not be returned to the merchant.\",\n    \"5-2\": \"Consumer should contact their network operator.\",\n    \"6-2\": \"Service has reached its 24 hour spend limit, which is typically £30. This limit lowers once 24 hours has elapsed since the oldest transaction has passed.\",\n    \"7-2\": \"Consumer failed the age verification check.\",\n    \"8-2\": \"Consumer clicked \\\"Exit\\\" within the payment flow.\",\n    \"9-2\": \"Payment failed due to insufficient credit.\",\n    \"2-0\": \"150\",\n    \"2-1\": \"Not charged\",\n    \"2-2\": \"Consumer has joined the service via a free trial and has not been charged but granted access.\",\n    \"10-0\": \"207\",\n    \"10-1\": \"Failed\",\n    \"10-2\": \"User asked to identify mobile network. This status code may be shown on the dashboard but will not be returned to the merchant.\",\n    \"12-0\": \"209\",\n    \"12-1\": \"Failed\",\n    \"13-2\": \"The tariff specified is not available on the consumers network.\",\n    \"13-1\": \"Failed\",\n    \"13-0\": \"210\",\n    \"12-2\": \"User is on the blacklist.\",\n    \"3-0\": \"160\",\n    \"3-1\": \"Already Billed\",\n    \"4-0\": \"170\",\n    \"4-1\": \"Already Billed\",\n    \"3-2\": \"Inactivity period extended, user given access to site.\",\n    \"4-2\": \"Consumer already paid for access.\",\n    \"11-0\": \"208\",\n    \"11-1\": \"Failed\",\n    \"11-2\": \"Recurring payment cancelled as 120 day deactivation rule has been reached and the consumer has not re-activated.\"\n  },\n  \"cols\": 3,\n  \"rows\": 14\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"danger\",\n  \"body\": \"Care should be taken when using real time alerts to ensure all errors are captured. This is to prevent an error potentially impacting the user experience and preventing them from completing their purchase.\",\n  \"title\": \"Real time alerts\",\n  \"sidebar\": true\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Example Requests\"\n}\n[/block]\nThis is an example of a Notify Billing Request for a one-off purchase. Note that the CampaignID, AffiliateID and Note parameters contain the data that was passed in to ImpulsePay via the ServiceURL. \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://merchantdomain.com/?MSISDN=447012345678&MSISDNType=ALIAS&PWID=20151201-PW12A4-45672BE8-91F2-34C5-B6DB-789A0F235A67&CampaignID=yourcampaignID&Tariff=900&Operator=o2_uk&Status=100&ExtendedStatus=100000&Billed=2015-12-01+14:58:19&ScreenshotURL=http://html.impulsepay.com/id.html&FlowMethod=Mobile&FlowType=MobileData&Note=yourcustomdata&AffiliateID=yourparam=yourdata;yourparam2=yourdata2&Useragent=&URLReferer=&FriendlyName=yourbuttonfriendlyname&AccessURL=yourServiceURL&TemplateID=yourTemplateID&TemplateName=yourTemplateName&AccountID=112925&RouteID=1000062\",\n      \"language\": \"http\",\n      \"name\": \"HTTP GET Request\"\n    }\n  ]\n}\n[/block]\nThis is an example of a Notify Billing request for initial subscription creation. Note that the RPID is the only recurring payment parameter sent in the first notification. Extended parameters will be sent from the second billing cycle. \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://merchantdomain.com/?MSISDN=447012345678&MSISDNType=ALIAS&PWID=20151201-PW12A4-45672BE8-91F2-34C5-B6DB-789A0F235A67&CampaignID=yourcampaignID&Tariff=900&Operator=o2_uk&Status=100&ExtendedStatus=100000&Billed=2015-12-01+14:58:19&ScreenshotURL=http://html.impulsepay.com/id.html&FlowMethod=Mobile&FlowType=MobileData&Note=yourcustomdata&AffiliateID=yourparam=yourdata;yourparam2=yourdata2&Useragent=&URLReferer=&FriendlyName=yourbuttonfriendlyname&AccessURL=yourServiceURL&TemplateID=yourTemplateID&TemplateName=yourTemplateName&AccountID=112925&RouteID=1000062&RPID=201511-RBILL2-1A-234567891-2345-6abc-78d9-e12f3456g7h8\",\n      \"language\": \"http\",\n      \"name\": \"HTTP GET Request\"\n    }\n  ]\n}\n[/block]\nThis is an example of a Notify Billing request for a recurring payment cycle. Note that this notification contains all the extended recurring payment parameters. \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://merchantdomain.com/?MSISDN=447012345678&MSISDNType=ALIAS&PWID=20151201-PW12A4-45672BE8-91F2-34C5-B6DB-789A0F235A67&CampaignID=yourcampaignID&Tariff=900&Operator=o2_uk&Status=100&ExtendedStatus=100000&Billed=2015-12-01+14:58:19&ScreenshotURL=http://html.impulsepay.com/id.html&FlowMethod=Mobile&FlowType=MobileData&Note=yourcustomdata&AffiliateID=yourparam=yourdata;yourparam2=yourdata2&Useragent=&URLReferer=&FriendlyName=yourbuttonfriendlyname&AccessURL=yourServiceURL&TemplateID=yourTemplateID&TemplateName=yourTemplateName&AccountID=112925&RouteID=1000062&RPID=201511-RBILL2-1A-234567891-2345-6abc-78d9-e12f3456g7h8&TimesBilled=2&LastReceiptSent=2015-11-30+14:58:19&NextCharge=2015-12-07+14:58:19&BillingPeriod=week&Frequency=1&createdAt=2015-11-23+14:58:19&LastInteraction=2015-11-23+14:59:30\",\n      \"language\": \"http\",\n      \"name\": \"HTTP GET Request\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Notification resend policy\"\n}\n[/block]\nOnce a billing notification has been sent to the merchant notification URL, ImpulsePay expects to get an HTTP 200 status code to indicate successfully acceptance of the billing notification. \n\nIf any other status code is returned, then ImpulsePay will attempt to resend this alert using an exponential back off policy for up to 14 attempts.\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Attempt Number\",\n    \"h-1\": \"Minutes\",\n    \"0-0\": \"1\",\n    \"1-0\": \"2\",\n    \"2-0\": \"3\",\n    \"3-0\": \"4\",\n    \"4-0\": \"5\",\n    \"5-0\": \"6\",\n    \"6-0\": \"7\",\n    \"7-0\": \"8\",\n    \"8-0\": \"9\",\n    \"9-0\": \"10\",\n    \"10-0\": \"11\",\n    \"11-0\": \"12\",\n    \"12-0\": \"13\",\n    \"13-0\": \"14\",\n    \"0-1\": \"2\",\n    \"1-1\": \"4\",\n    \"2-1\": \"8\",\n    \"3-1\": \"16\",\n    \"4-1\": \"32\",\n    \"5-1\": \"64\",\n    \"6-1\": \"128\",\n    \"7-1\": \"256\",\n    \"8-1\": \"512\",\n    \"9-1\": \"1024\",\n    \"10-1\": \"2048\",\n    \"11-1\": \"4096\",\n    \"12-1\": \"8192\",\n    \"13-1\": \"16384\"\n  },\n  \"cols\": 2,\n  \"rows\": 14\n}\n[/block]","category":"564b0edd1a8e610d006bfce1","createdAt":"2015-02-23T15:07:51.437Z","excerpt":"Status codes that relate specifically to the result of a transaction","githubsync":"","hidden":false,"isReference":false,"link_external":false,"link_url":"","order":0,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"billing-status-codes","sync_unique":"","title":"Notify Billing","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Notify Billing

Status codes that relate specifically to the result of a transaction

Payment alerts are sent in real time, as a payment is being processed. For services using recurring payments, these alerts are sent once a payment has been processed. Billing notifications are made to a merchant using an HTTP(s) GET in real time. The URL should be updated using the Config page on the Dashboard and once configured, the following parameters are passed on each request. Notifications are sent before the consumer is redirected to the Success or Failure URL. In the case of a notification failing to be delivered, it will be retried according to the notification retry policy and the consumer will be forwarded to the success or failure URL. Merchants can append their own static parameters to the Notification URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "3-0": "CampaignID", "4-0": "Tariff", "5-0": "Operator", "6-0": "Status", "7-0": "ExtendedStatus", "8-0": "Billed", "9-0": "ScreenshotURL", "10-0": "FlowMethod", "11-0": "FlowType", "12-0": "Note", "13-0": "AffiliateID", "14-0": "Useragent", "15-0": "URLReferer", "16-0": "FriendlyName", "17-0": "AccessURL", "3-1": "The CampaignID specified for this request.", "4-1": "The tariff (in pence) that the consumer was purchased.", "5-1": "The consumers mobile operator.", "6-1": "Status code for this transaction.", "7-1": "The extended status code for this transaction.", "8-1": "Timestamp of the transaction.", "9-1": "URL to the screenshot taken for this transaction.", "10-1": "The device type used for this transaction.", "11-1": "The verification method that was used for the payment.", "12-1": "The merchant can use the note for passing custom parameters through. These will be returned to the merchant in the billing notification. This can be a maximum of 250 characters.", "13-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "14-1": "The user agent type for which the transaction was processed for.", "15-1": "URL referrer, SMS message text used to access service by (when known).", "16-1": "FriendlyName that was passed in through the button on the Paywall engine.", "17-1": "URL used to access the site by the consumer.", "3-2": "ABC123", "4-2": "450 for £4.50", "5-2": "o2_uk,\norange_uk,\nthree_uk,\ntmobile_uk,\nvirgin_uk,\nvodafone_uk", "6-2": "100", "7-2": "See 'Operator Status codes' section", "8-2": "YYYY-MM-DD HH:HH:SS", "9-2": "http://html.impulsepay.com/{ID}.html", "10-2": "Desktop\nMobile\niPad\niPhone\nAndroid", "11-2": "**SMS** - SMS marketing message link used\n**MobileData** - 3G/ 4G data verification\n**MT Link **- Consumer entered MSISDN\n**IVR Call** - Consumer called IVR line\n**MO Msg** - Consumer texted keyword\n**Repeat **- Recurring payment", "12-2": "Param1#Param2#Param3", "13-2": "A=1;B=2", "14-2": "Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10.", "16-2": "Access24Hrs3", "15-2": "Http://www.google.com", "17-2": "http://m.merchantsite.com/1000/ABC123", "0-0": "MSISDN", "1-0": "MSISDNType", "0-1": "The MSISDN or Alias for the consumer.", "1-1": "Flag to specify if this is a MSISDN or ALIAS being passed.", "0-2": "447123123123", "1-2": "MSISDN | ALIAS", "2-0": "PWID", "2-1": "A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.", "2-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "18-0": "TemplateID", "19-0": "TemplateName", "20-0": "AccountID", "21-0": "RouteID", "18-1": "The unique ID for the payment page used for the payment.", "19-1": "The name given to the template by the merchant.", "20-1": "The merchants AccountID.", "21-1": "The RouteID used for the purchase.", "20-2": "112900", "21-2": "1000123", "19-2": "YourTemplate", "18-2": "ABC-123" }, "cols": 3, "rows": 22 } [/block] Additional parameters for Repeat billing notifications will be sent once the first recurring payment is made. Only the RPID will be sent after the initial charge and creation of the recurring payment. Please note that when using Testmode, the RPID and additional parameters will not be delivered, as no Recurring Payment is established. You may use the RPID example below to simulate the RPID inclusion in Notify Billing. [block:parameters] { "data": { "h-0": "Parameters", "h-1": "Description", "h-2": "Example", "0-0": "RPID", "0-1": "Unique ID to identify this recurring payment subscription that stays persistent across all notifications for this subscription.", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-0": "TimesBilled", "1-1": "Number of times the MSISDN has been billed in this recurring payment cycle.", "1-2": "4", "2-0": "LastReceiptSent", "2-1": "The date the last reminder text was sent for either £20 spend or 30 day reminder.", "3-0": "NextCharge", "3-1": "The date for when the next charge is scheduled to be made, if not cancelled by the user.", "3-2": "YYYY-MM-DD HH:MM:SS", "4-0": "BillingPeriod", "4-1": "Period of the recurring charges.", "4-2": "WEEK\nMONTH", "5-0": "Frequency", "5-1": "Frequency of the recurring charges.", "5-2": "7", "6-0": "CreatedAt", "6-1": "Date that the user opted into the recurring payment.", "7-0": "LastInteraction", "7-1": "The last time the service was used (this is used to define the starting point of the 120 day inactivity rule).", "2-2": "YYYY-MM-DD HH:MM:SS", "6-2": "YYYY-MM-DD HH:MM:SS", "7-2": "YYYY-MM-DD HH:MM:SS" }, "cols": 3, "rows": 8 } [/block] BillingStatus will consist of these codes: [block:parameters] { "data": { "h-0": "Status Code", "h-1": "Meaning", "0-0": "100", "1-0": "140", "0-1": "Billed", "1-1": "In Progress", "5-0": "200", "5-1": "Failed", "6-0": "201", "6-1": "Failed", "7-0": "202", "7-1": "Failed", "8-0": "203", "8-1": "Failed", "9-0": "204", "9-1": "Failed", "h-2": "Description", "0-2": "Billed Successfully.", "1-2": "Attempting to bill. Status should update to a 100 or 20x range code shortly. This status code may be shown on the dashboard but will not be returned to the merchant.", "5-2": "Consumer should contact their network operator.", "6-2": "Service has reached its 24 hour spend limit, which is typically £30. This limit lowers once 24 hours has elapsed since the oldest transaction has passed.", "7-2": "Consumer failed the age verification check.", "8-2": "Consumer clicked \"Exit\" within the payment flow.", "9-2": "Payment failed due to insufficient credit.", "2-0": "150", "2-1": "Not charged", "2-2": "Consumer has joined the service via a free trial and has not been charged but granted access.", "10-0": "207", "10-1": "Failed", "10-2": "User asked to identify mobile network. This status code may be shown on the dashboard but will not be returned to the merchant.", "12-0": "209", "12-1": "Failed", "13-2": "The tariff specified is not available on the consumers network.", "13-1": "Failed", "13-0": "210", "12-2": "User is on the blacklist.", "3-0": "160", "3-1": "Already Billed", "4-0": "170", "4-1": "Already Billed", "3-2": "Inactivity period extended, user given access to site.", "4-2": "Consumer already paid for access.", "11-0": "208", "11-1": "Failed", "11-2": "Recurring payment cancelled as 120 day deactivation rule has been reached and the consumer has not re-activated." }, "cols": 3, "rows": 14 } [/block] [block:callout] { "type": "danger", "body": "Care should be taken when using real time alerts to ensure all errors are captured. This is to prevent an error potentially impacting the user experience and preventing them from completing their purchase.", "title": "Real time alerts", "sidebar": true } [/block] [block:api-header] { "type": "basic", "title": "Example Requests" } [/block] This is an example of a Notify Billing Request for a one-off purchase. Note that the CampaignID, AffiliateID and Note parameters contain the data that was passed in to ImpulsePay via the ServiceURL. [block:code] { "codes": [ { "code": "http://merchantdomain.com/?MSISDN=447012345678&MSISDNType=ALIAS&PWID=20151201-PW12A4-45672BE8-91F2-34C5-B6DB-789A0F235A67&CampaignID=yourcampaignID&Tariff=900&Operator=o2_uk&Status=100&ExtendedStatus=100000&Billed=2015-12-01+14:58:19&ScreenshotURL=http://html.impulsepay.com/id.html&FlowMethod=Mobile&FlowType=MobileData&Note=yourcustomdata&AffiliateID=yourparam=yourdata;yourparam2=yourdata2&Useragent=&URLReferer=&FriendlyName=yourbuttonfriendlyname&AccessURL=yourServiceURL&TemplateID=yourTemplateID&TemplateName=yourTemplateName&AccountID=112925&RouteID=1000062", "language": "http", "name": "HTTP GET Request" } ] } [/block] This is an example of a Notify Billing request for initial subscription creation. Note that the RPID is the only recurring payment parameter sent in the first notification. Extended parameters will be sent from the second billing cycle. [block:code] { "codes": [ { "code": "http://merchantdomain.com/?MSISDN=447012345678&MSISDNType=ALIAS&PWID=20151201-PW12A4-45672BE8-91F2-34C5-B6DB-789A0F235A67&CampaignID=yourcampaignID&Tariff=900&Operator=o2_uk&Status=100&ExtendedStatus=100000&Billed=2015-12-01+14:58:19&ScreenshotURL=http://html.impulsepay.com/id.html&FlowMethod=Mobile&FlowType=MobileData&Note=yourcustomdata&AffiliateID=yourparam=yourdata;yourparam2=yourdata2&Useragent=&URLReferer=&FriendlyName=yourbuttonfriendlyname&AccessURL=yourServiceURL&TemplateID=yourTemplateID&TemplateName=yourTemplateName&AccountID=112925&RouteID=1000062&RPID=201511-RBILL2-1A-234567891-2345-6abc-78d9-e12f3456g7h8", "language": "http", "name": "HTTP GET Request" } ] } [/block] This is an example of a Notify Billing request for a recurring payment cycle. Note that this notification contains all the extended recurring payment parameters. [block:code] { "codes": [ { "code": "http://merchantdomain.com/?MSISDN=447012345678&MSISDNType=ALIAS&PWID=20151201-PW12A4-45672BE8-91F2-34C5-B6DB-789A0F235A67&CampaignID=yourcampaignID&Tariff=900&Operator=o2_uk&Status=100&ExtendedStatus=100000&Billed=2015-12-01+14:58:19&ScreenshotURL=http://html.impulsepay.com/id.html&FlowMethod=Mobile&FlowType=MobileData&Note=yourcustomdata&AffiliateID=yourparam=yourdata;yourparam2=yourdata2&Useragent=&URLReferer=&FriendlyName=yourbuttonfriendlyname&AccessURL=yourServiceURL&TemplateID=yourTemplateID&TemplateName=yourTemplateName&AccountID=112925&RouteID=1000062&RPID=201511-RBILL2-1A-234567891-2345-6abc-78d9-e12f3456g7h8&TimesBilled=2&LastReceiptSent=2015-11-30+14:58:19&NextCharge=2015-12-07+14:58:19&BillingPeriod=week&Frequency=1&createdAt=2015-11-23+14:58:19&LastInteraction=2015-11-23+14:59:30", "language": "http", "name": "HTTP GET Request" } ] } [/block] [block:api-header] { "type": "basic", "title": "Notification resend policy" } [/block] Once a billing notification has been sent to the merchant notification URL, ImpulsePay expects to get an HTTP 200 status code to indicate successfully acceptance of the billing notification. If any other status code is returned, then ImpulsePay will attempt to resend this alert using an exponential back off policy for up to 14 attempts. [block:parameters] { "data": { "h-0": "Attempt Number", "h-1": "Minutes", "0-0": "1", "1-0": "2", "2-0": "3", "3-0": "4", "4-0": "5", "5-0": "6", "6-0": "7", "7-0": "8", "8-0": "9", "9-0": "10", "10-0": "11", "11-0": "12", "12-0": "13", "13-0": "14", "0-1": "2", "1-1": "4", "2-1": "8", "3-1": "16", "4-1": "32", "5-1": "64", "6-1": "128", "7-1": "256", "8-1": "512", "9-1": "1024", "10-1": "2048", "11-1": "4096", "12-1": "8192", "13-1": "16384" }, "cols": 2, "rows": 14 } [/block]
Payment alerts are sent in real time, as a payment is being processed. For services using recurring payments, these alerts are sent once a payment has been processed. Billing notifications are made to a merchant using an HTTP(s) GET in real time. The URL should be updated using the Config page on the Dashboard and once configured, the following parameters are passed on each request. Notifications are sent before the consumer is redirected to the Success or Failure URL. In the case of a notification failing to be delivered, it will be retried according to the notification retry policy and the consumer will be forwarded to the success or failure URL. Merchants can append their own static parameters to the Notification URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "3-0": "CampaignID", "4-0": "Tariff", "5-0": "Operator", "6-0": "Status", "7-0": "ExtendedStatus", "8-0": "Billed", "9-0": "ScreenshotURL", "10-0": "FlowMethod", "11-0": "FlowType", "12-0": "Note", "13-0": "AffiliateID", "14-0": "Useragent", "15-0": "URLReferer", "16-0": "FriendlyName", "17-0": "AccessURL", "3-1": "The CampaignID specified for this request.", "4-1": "The tariff (in pence) that the consumer was purchased.", "5-1": "The consumers mobile operator.", "6-1": "Status code for this transaction.", "7-1": "The extended status code for this transaction.", "8-1": "Timestamp of the transaction.", "9-1": "URL to the screenshot taken for this transaction.", "10-1": "The device type used for this transaction.", "11-1": "The verification method that was used for the payment.", "12-1": "The merchant can use the note for passing custom parameters through. These will be returned to the merchant in the billing notification. This can be a maximum of 250 characters.", "13-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "14-1": "The user agent type for which the transaction was processed for.", "15-1": "URL referrer, SMS message text used to access service by (when known).", "16-1": "FriendlyName that was passed in through the button on the Paywall engine.", "17-1": "URL used to access the site by the consumer.", "3-2": "ABC123", "4-2": "450 for £4.50", "5-2": "o2_uk,\norange_uk,\nthree_uk,\ntmobile_uk,\nvirgin_uk,\nvodafone_uk", "6-2": "100", "7-2": "See 'Operator Status codes' section", "8-2": "YYYY-MM-DD HH:HH:SS", "9-2": "http://html.impulsepay.com/{ID}.html", "10-2": "Desktop\nMobile\niPad\niPhone\nAndroid", "11-2": "**SMS** - SMS marketing message link used\n**MobileData** - 3G/ 4G data verification\n**MT Link **- Consumer entered MSISDN\n**IVR Call** - Consumer called IVR line\n**MO Msg** - Consumer texted keyword\n**Repeat **- Recurring payment", "12-2": "Param1#Param2#Param3", "13-2": "A=1;B=2", "14-2": "Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10.", "16-2": "Access24Hrs3", "15-2": "Http://www.google.com", "17-2": "http://m.merchantsite.com/1000/ABC123", "0-0": "MSISDN", "1-0": "MSISDNType", "0-1": "The MSISDN or Alias for the consumer.", "1-1": "Flag to specify if this is a MSISDN or ALIAS being passed.", "0-2": "447123123123", "1-2": "MSISDN | ALIAS", "2-0": "PWID", "2-1": "A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.", "2-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "18-0": "TemplateID", "19-0": "TemplateName", "20-0": "AccountID", "21-0": "RouteID", "18-1": "The unique ID for the payment page used for the payment.", "19-1": "The name given to the template by the merchant.", "20-1": "The merchants AccountID.", "21-1": "The RouteID used for the purchase.", "20-2": "112900", "21-2": "1000123", "19-2": "YourTemplate", "18-2": "ABC-123" }, "cols": 3, "rows": 22 } [/block] Additional parameters for Repeat billing notifications will be sent once the first recurring payment is made. Only the RPID will be sent after the initial charge and creation of the recurring payment. Please note that when using Testmode, the RPID and additional parameters will not be delivered, as no Recurring Payment is established. You may use the RPID example below to simulate the RPID inclusion in Notify Billing. [block:parameters] { "data": { "h-0": "Parameters", "h-1": "Description", "h-2": "Example", "0-0": "RPID", "0-1": "Unique ID to identify this recurring payment subscription that stays persistent across all notifications for this subscription.", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-0": "TimesBilled", "1-1": "Number of times the MSISDN has been billed in this recurring payment cycle.", "1-2": "4", "2-0": "LastReceiptSent", "2-1": "The date the last reminder text was sent for either £20 spend or 30 day reminder.", "3-0": "NextCharge", "3-1": "The date for when the next charge is scheduled to be made, if not cancelled by the user.", "3-2": "YYYY-MM-DD HH:MM:SS", "4-0": "BillingPeriod", "4-1": "Period of the recurring charges.", "4-2": "WEEK\nMONTH", "5-0": "Frequency", "5-1": "Frequency of the recurring charges.", "5-2": "7", "6-0": "CreatedAt", "6-1": "Date that the user opted into the recurring payment.", "7-0": "LastInteraction", "7-1": "The last time the service was used (this is used to define the starting point of the 120 day inactivity rule).", "2-2": "YYYY-MM-DD HH:MM:SS", "6-2": "YYYY-MM-DD HH:MM:SS", "7-2": "YYYY-MM-DD HH:MM:SS" }, "cols": 3, "rows": 8 } [/block] BillingStatus will consist of these codes: [block:parameters] { "data": { "h-0": "Status Code", "h-1": "Meaning", "0-0": "100", "1-0": "140", "0-1": "Billed", "1-1": "In Progress", "5-0": "200", "5-1": "Failed", "6-0": "201", "6-1": "Failed", "7-0": "202", "7-1": "Failed", "8-0": "203", "8-1": "Failed", "9-0": "204", "9-1": "Failed", "h-2": "Description", "0-2": "Billed Successfully.", "1-2": "Attempting to bill. Status should update to a 100 or 20x range code shortly. This status code may be shown on the dashboard but will not be returned to the merchant.", "5-2": "Consumer should contact their network operator.", "6-2": "Service has reached its 24 hour spend limit, which is typically £30. This limit lowers once 24 hours has elapsed since the oldest transaction has passed.", "7-2": "Consumer failed the age verification check.", "8-2": "Consumer clicked \"Exit\" within the payment flow.", "9-2": "Payment failed due to insufficient credit.", "2-0": "150", "2-1": "Not charged", "2-2": "Consumer has joined the service via a free trial and has not been charged but granted access.", "10-0": "207", "10-1": "Failed", "10-2": "User asked to identify mobile network. This status code may be shown on the dashboard but will not be returned to the merchant.", "12-0": "209", "12-1": "Failed", "13-2": "The tariff specified is not available on the consumers network.", "13-1": "Failed", "13-0": "210", "12-2": "User is on the blacklist.", "3-0": "160", "3-1": "Already Billed", "4-0": "170", "4-1": "Already Billed", "3-2": "Inactivity period extended, user given access to site.", "4-2": "Consumer already paid for access.", "11-0": "208", "11-1": "Failed", "11-2": "Recurring payment cancelled as 120 day deactivation rule has been reached and the consumer has not re-activated." }, "cols": 3, "rows": 14 } [/block] [block:callout] { "type": "danger", "body": "Care should be taken when using real time alerts to ensure all errors are captured. This is to prevent an error potentially impacting the user experience and preventing them from completing their purchase.", "title": "Real time alerts", "sidebar": true } [/block] [block:api-header] { "type": "basic", "title": "Example Requests" } [/block] This is an example of a Notify Billing Request for a one-off purchase. Note that the CampaignID, AffiliateID and Note parameters contain the data that was passed in to ImpulsePay via the ServiceURL. [block:code] { "codes": [ { "code": "http://merchantdomain.com/?MSISDN=447012345678&MSISDNType=ALIAS&PWID=20151201-PW12A4-45672BE8-91F2-34C5-B6DB-789A0F235A67&CampaignID=yourcampaignID&Tariff=900&Operator=o2_uk&Status=100&ExtendedStatus=100000&Billed=2015-12-01+14:58:19&ScreenshotURL=http://html.impulsepay.com/id.html&FlowMethod=Mobile&FlowType=MobileData&Note=yourcustomdata&AffiliateID=yourparam=yourdata;yourparam2=yourdata2&Useragent=&URLReferer=&FriendlyName=yourbuttonfriendlyname&AccessURL=yourServiceURL&TemplateID=yourTemplateID&TemplateName=yourTemplateName&AccountID=112925&RouteID=1000062", "language": "http", "name": "HTTP GET Request" } ] } [/block] This is an example of a Notify Billing request for initial subscription creation. Note that the RPID is the only recurring payment parameter sent in the first notification. Extended parameters will be sent from the second billing cycle. [block:code] { "codes": [ { "code": "http://merchantdomain.com/?MSISDN=447012345678&MSISDNType=ALIAS&PWID=20151201-PW12A4-45672BE8-91F2-34C5-B6DB-789A0F235A67&CampaignID=yourcampaignID&Tariff=900&Operator=o2_uk&Status=100&ExtendedStatus=100000&Billed=2015-12-01+14:58:19&ScreenshotURL=http://html.impulsepay.com/id.html&FlowMethod=Mobile&FlowType=MobileData&Note=yourcustomdata&AffiliateID=yourparam=yourdata;yourparam2=yourdata2&Useragent=&URLReferer=&FriendlyName=yourbuttonfriendlyname&AccessURL=yourServiceURL&TemplateID=yourTemplateID&TemplateName=yourTemplateName&AccountID=112925&RouteID=1000062&RPID=201511-RBILL2-1A-234567891-2345-6abc-78d9-e12f3456g7h8", "language": "http", "name": "HTTP GET Request" } ] } [/block] This is an example of a Notify Billing request for a recurring payment cycle. Note that this notification contains all the extended recurring payment parameters. [block:code] { "codes": [ { "code": "http://merchantdomain.com/?MSISDN=447012345678&MSISDNType=ALIAS&PWID=20151201-PW12A4-45672BE8-91F2-34C5-B6DB-789A0F235A67&CampaignID=yourcampaignID&Tariff=900&Operator=o2_uk&Status=100&ExtendedStatus=100000&Billed=2015-12-01+14:58:19&ScreenshotURL=http://html.impulsepay.com/id.html&FlowMethod=Mobile&FlowType=MobileData&Note=yourcustomdata&AffiliateID=yourparam=yourdata;yourparam2=yourdata2&Useragent=&URLReferer=&FriendlyName=yourbuttonfriendlyname&AccessURL=yourServiceURL&TemplateID=yourTemplateID&TemplateName=yourTemplateName&AccountID=112925&RouteID=1000062&RPID=201511-RBILL2-1A-234567891-2345-6abc-78d9-e12f3456g7h8&TimesBilled=2&LastReceiptSent=2015-11-30+14:58:19&NextCharge=2015-12-07+14:58:19&BillingPeriod=week&Frequency=1&createdAt=2015-11-23+14:58:19&LastInteraction=2015-11-23+14:59:30", "language": "http", "name": "HTTP GET Request" } ] } [/block] [block:api-header] { "type": "basic", "title": "Notification resend policy" } [/block] Once a billing notification has been sent to the merchant notification URL, ImpulsePay expects to get an HTTP 200 status code to indicate successfully acceptance of the billing notification. If any other status code is returned, then ImpulsePay will attempt to resend this alert using an exponential back off policy for up to 14 attempts. [block:parameters] { "data": { "h-0": "Attempt Number", "h-1": "Minutes", "0-0": "1", "1-0": "2", "2-0": "3", "3-0": "4", "4-0": "5", "5-0": "6", "6-0": "7", "7-0": "8", "8-0": "9", "9-0": "10", "10-0": "11", "11-0": "12", "12-0": "13", "13-0": "14", "0-1": "2", "1-1": "4", "2-1": "8", "3-1": "16", "4-1": "32", "5-1": "64", "6-1": "128", "7-1": "256", "8-1": "512", "9-1": "1024", "10-1": "2048", "11-1": "4096", "12-1": "8192", "13-1": "16384" }, "cols": 2, "rows": 14 } [/block]
{"__v":11,"_id":"5524f5bdd919032b0057ac3f","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"A consumer can cancel a recurring payment at any time by texting STOP to 89365. When this happens they are unsubscribed from all active services immediately. \n\nWhen a user texts STOP, a notification can be passed to the merchant's services. ImpulsePay will also send a notification for automatically cancelled subscriptions that have not successfully billed in 3 months. Both notifications will be passed using a GET request using the following URL format: \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://domain.com/page?MSISDN=&MSISDNAlias=&TransID=\",\n      \"language\": \"http\",\n      \"name\": \"Notify Unsubscribe\"\n    }\n  ]\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://domain.com/page?MSISDN=&MSISDNAlias=&TransID=&Type=Expired \",\n      \"language\": \"text\",\n      \"name\": \"Notify Expiry\"\n    }\n  ]\n}\n[/block]\nThe following parameters will be expected:\n[block:parameters]\n{\n  \"data\": {\n    \"0-0\": \"MSISDN\",\n    \"1-0\": \"MSISDNAlias\",\n    \"2-0\": \"TransID\",\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-2\": \"447000111222\",\n    \"1-2\": \"440000000000\",\n    \"2-2\": \"201502-PFISC6-839abe2c-1daf-44a7-85d0-e74ecb1e23c8\",\n    \"0-1\": \"The consumers mobile number.\",\n    \"1-1\": \"The alias for the MSISDN, if one has been created previously.\",\n    \"2-1\": \"A unique 50 character ID for this request, which will stay persistent if the notification is retried.\"\n  },\n  \"cols\": 3,\n  \"rows\": 3\n}\n[/block]\nMerchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.\n\nShould a notification fail then it will be retried using the following exponential back off retry policy:\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Attempts\",\n    \"h-1\": \"Minutes\",\n    \"0-0\": \"1\",\n    \"1-0\": \"2\",\n    \"2-0\": \"3\",\n    \"3-0\": \"4\",\n    \"4-0\": \"5\",\n    \"5-0\": \"6\",\n    \"6-0\": \"7\",\n    \"7-0\": \"8\",\n    \"8-0\": \"9\",\n    \"9-0\": \"10\",\n    \"10-0\": \"11\",\n    \"11-0\": \"12\",\n    \"12-0\": \"13\",\n    \"13-0\": \"14\",\n    \"0-1\": \"2\",\n    \"1-1\": \"4\",\n    \"2-1\": \"8\",\n    \"3-1\": \"16\",\n    \"4-1\": \"32\",\n    \"5-1\": \"64\",\n    \"6-1\": \"128\",\n    \"7-1\": \"256\",\n    \"8-1\": \"512\",\n    \"9-1\": \"1024\",\n    \"10-1\": \"2048\",\n    \"11-1\": \"4096\",\n    \"12-1\": \"8192\",\n    \"13-1\": \"16384\"\n  },\n  \"cols\": 2,\n  \"rows\": 14\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"A user can unsubscribe from a service by texting STOP to 89365. This will stop all future payments, however access they have already paid for should continue until this time period has expired.\",\n  \"title\": \"Unsubscribing\",\n  \"sidebar\": true\n}\n[/block]","category":"564b0edd1a8e610d006bfce1","createdAt":"2015-02-25T11:40:35.763Z","excerpt":"Getting alerted when people unsubscribe from a recurring payment","githubsync":"","hidden":false,"isReference":false,"link_external":false,"link_url":"","order":1,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"unsubscribing","sync_unique":"","title":"Notify Unsubscribe / Expiry","type":"basic","updates":[],"user":"54eb3aaedf7add210007b26a","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Notify Unsubscribe / Expiry

Getting alerted when people unsubscribe from a recurring payment

A consumer can cancel a recurring payment at any time by texting STOP to 89365. When this happens they are unsubscribed from all active services immediately. When a user texts STOP, a notification can be passed to the merchant's services. ImpulsePay will also send a notification for automatically cancelled subscriptions that have not successfully billed in 3 months. Both notifications will be passed using a GET request using the following URL format: [block:code] { "codes": [ { "code": "http://domain.com/page?MSISDN=&MSISDNAlias=&TransID=", "language": "http", "name": "Notify Unsubscribe" } ] } [/block] [block:code] { "codes": [ { "code": "http://domain.com/page?MSISDN=&MSISDNAlias=&TransID=&Type=Expired ", "language": "text", "name": "Notify Expiry" } ] } [/block] The following parameters will be expected: [block:parameters] { "data": { "0-0": "MSISDN", "1-0": "MSISDNAlias", "2-0": "TransID", "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-2": "447000111222", "1-2": "440000000000", "2-2": "201502-PFISC6-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "0-1": "The consumers mobile number.", "1-1": "The alias for the MSISDN, if one has been created previously.", "2-1": "A unique 50 character ID for this request, which will stay persistent if the notification is retried." }, "cols": 3, "rows": 3 } [/block] Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. Should a notification fail then it will be retried using the following exponential back off retry policy: [block:parameters] { "data": { "h-0": "Attempts", "h-1": "Minutes", "0-0": "1", "1-0": "2", "2-0": "3", "3-0": "4", "4-0": "5", "5-0": "6", "6-0": "7", "7-0": "8", "8-0": "9", "9-0": "10", "10-0": "11", "11-0": "12", "12-0": "13", "13-0": "14", "0-1": "2", "1-1": "4", "2-1": "8", "3-1": "16", "4-1": "32", "5-1": "64", "6-1": "128", "7-1": "256", "8-1": "512", "9-1": "1024", "10-1": "2048", "11-1": "4096", "12-1": "8192", "13-1": "16384" }, "cols": 2, "rows": 14 } [/block] [block:callout] { "type": "info", "body": "A user can unsubscribe from a service by texting STOP to 89365. This will stop all future payments, however access they have already paid for should continue until this time period has expired.", "title": "Unsubscribing", "sidebar": true } [/block]
A consumer can cancel a recurring payment at any time by texting STOP to 89365. When this happens they are unsubscribed from all active services immediately. When a user texts STOP, a notification can be passed to the merchant's services. ImpulsePay will also send a notification for automatically cancelled subscriptions that have not successfully billed in 3 months. Both notifications will be passed using a GET request using the following URL format: [block:code] { "codes": [ { "code": "http://domain.com/page?MSISDN=&MSISDNAlias=&TransID=", "language": "http", "name": "Notify Unsubscribe" } ] } [/block] [block:code] { "codes": [ { "code": "http://domain.com/page?MSISDN=&MSISDNAlias=&TransID=&Type=Expired ", "language": "text", "name": "Notify Expiry" } ] } [/block] The following parameters will be expected: [block:parameters] { "data": { "0-0": "MSISDN", "1-0": "MSISDNAlias", "2-0": "TransID", "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-2": "447000111222", "1-2": "440000000000", "2-2": "201502-PFISC6-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "0-1": "The consumers mobile number.", "1-1": "The alias for the MSISDN, if one has been created previously.", "2-1": "A unique 50 character ID for this request, which will stay persistent if the notification is retried." }, "cols": 3, "rows": 3 } [/block] Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. Should a notification fail then it will be retried using the following exponential back off retry policy: [block:parameters] { "data": { "h-0": "Attempts", "h-1": "Minutes", "0-0": "1", "1-0": "2", "2-0": "3", "3-0": "4", "4-0": "5", "5-0": "6", "6-0": "7", "7-0": "8", "8-0": "9", "9-0": "10", "10-0": "11", "11-0": "12", "12-0": "13", "13-0": "14", "0-1": "2", "1-1": "4", "2-1": "8", "3-1": "16", "4-1": "32", "5-1": "64", "6-1": "128", "7-1": "256", "8-1": "512", "9-1": "1024", "10-1": "2048", "11-1": "4096", "12-1": "8192", "13-1": "16384" }, "cols": 2, "rows": 14 } [/block] [block:callout] { "type": "info", "body": "A user can unsubscribe from a service by texting STOP to 89365. This will stop all future payments, however access they have already paid for should continue until this time period has expired.", "title": "Unsubscribing", "sidebar": true } [/block]
{"__v":16,"_id":"553110382e11b21900523565","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"This API can be used to notify the merchant each time the PaymentPage is requested. To activate it, simply enter the URL into the Config page on the dashboard.\n[block:api-header]\n{\n  \"type\": \"basic\"\n}\n[/block]\nThe following parameters are returned on each request\n[block:parameters]\n{\n  \"data\": {\n    \"0-0\": \"PWID\",\n    \"1-0\": \"CampaignID\",\n    \"4-0\": \"FlowType\",\n    \"5-0\": \"Useragent\",\n    \"8-0\": \"AccessURL\",\n    \"9-0\": \"TemplateID\",\n    \"11-0\": \"Logged\",\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-1\": \"A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.\",\n    \"1-1\": \"The CampaignID specified for this request\",\n    \"8-1\": \"The URL the consumer has used to access the service\",\n    \"5-1\": \"The user agent type for which the transaction was processed for\",\n    \"4-1\": \"The verification method that was used for the payment\",\n    \"9-1\": \"Unique 60 character ID displayed to the consumer\",\n    \"11-1\": \"Timestamp of when the page was served to the consumer\",\n    \"0-2\": \"201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8\",\n    \"1-2\": \"ABC123\",\n    \"4-2\": \"**SMS** - SMS marketing message link used\\n**MobileData** - 3G/ 4G data verification\\n**MT Link **- Consumer entered MSISDN\\n**IVR Call** - Consumer called IVR line\\n**MO Msg** - Consumer texted keyword\\n**Repeat **- Recurring payment\",\n    \"5-2\": \"Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10.\",\n    \"8-2\": \"http://angelfish1.impulsepay.com/yourpage\",\n    \"9-2\": \"754YUCSJO-D09EE0E7-AB97-4A21-9T50-AB62967D0F54FFC412136342A3\",\n    \"11-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"2-0\": \"Note\",\n    \"2-1\": \"Merchant specific parameters\",\n    \"2-2\": \"Param1#Param2#Param3\",\n    \"3-0\": \"AffiliateID\",\n    \"3-1\": \"Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.\",\n    \"3-2\": \"A=1;B=2\",\n    \"6-0\": \"URLReferer\",\n    \"6-1\": \"The URL referrer or SMS message text used to access service (when known)\",\n    \"6-2\": \"http://www.google.com\",\n    \"10-0\": \"TemplateName\",\n    \"10-1\": \"The saved name of the template displayed to the consumer\",\n    \"10-2\": \"\\\"MobileB1\\\"\",\n    \"7-0\": \"RefererIP\",\n    \"7-1\": \"IP address header information of the user\"\n  },\n  \"cols\": 3,\n  \"rows\": 12\n}\n[/block]\nMerchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.\n\nDue to the volume of hits, ImpulsePay will not retry these notifications in the event of a merchant failure, however the same information is available on the detailed dashboard.","category":"564b0edd1a8e610d006bfce1","createdAt":"2015-04-17T13:52:56.653Z","excerpt":"This API allows the merchant to be informed each time their PaymentPage is loaded","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":2,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"notify-impression","sync_unique":"","title":"Notify Impression","type":"basic","updates":[],"user":"54eb3aaedf7add210007b26a","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Notify Impression

This API allows the merchant to be informed each time their PaymentPage is loaded

This API can be used to notify the merchant each time the PaymentPage is requested. To activate it, simply enter the URL into the Config page on the dashboard. [block:api-header] { "type": "basic" } [/block] The following parameters are returned on each request [block:parameters] { "data": { "0-0": "PWID", "1-0": "CampaignID", "4-0": "FlowType", "5-0": "Useragent", "8-0": "AccessURL", "9-0": "TemplateID", "11-0": "Logged", "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-1": "A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.", "1-1": "The CampaignID specified for this request", "8-1": "The URL the consumer has used to access the service", "5-1": "The user agent type for which the transaction was processed for", "4-1": "The verification method that was used for the payment", "9-1": "Unique 60 character ID displayed to the consumer", "11-1": "Timestamp of when the page was served to the consumer", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-2": "ABC123", "4-2": "**SMS** - SMS marketing message link used\n**MobileData** - 3G/ 4G data verification\n**MT Link **- Consumer entered MSISDN\n**IVR Call** - Consumer called IVR line\n**MO Msg** - Consumer texted keyword\n**Repeat **- Recurring payment", "5-2": "Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10.", "8-2": "http://angelfish1.impulsepay.com/yourpage", "9-2": "754YUCSJO-D09EE0E7-AB97-4A21-9T50-AB62967D0F54FFC412136342A3", "11-2": "YYYY-MM-DD HH:MM:SS", "2-0": "Note", "2-1": "Merchant specific parameters", "2-2": "Param1#Param2#Param3", "3-0": "AffiliateID", "3-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "3-2": "A=1;B=2", "6-0": "URLReferer", "6-1": "The URL referrer or SMS message text used to access service (when known)", "6-2": "http://www.google.com", "10-0": "TemplateName", "10-1": "The saved name of the template displayed to the consumer", "10-2": "\"MobileB1\"", "7-0": "RefererIP", "7-1": "IP address header information of the user" }, "cols": 3, "rows": 12 } [/block] Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. Due to the volume of hits, ImpulsePay will not retry these notifications in the event of a merchant failure, however the same information is available on the detailed dashboard.
This API can be used to notify the merchant each time the PaymentPage is requested. To activate it, simply enter the URL into the Config page on the dashboard. [block:api-header] { "type": "basic" } [/block] The following parameters are returned on each request [block:parameters] { "data": { "0-0": "PWID", "1-0": "CampaignID", "4-0": "FlowType", "5-0": "Useragent", "8-0": "AccessURL", "9-0": "TemplateID", "11-0": "Logged", "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-1": "A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.", "1-1": "The CampaignID specified for this request", "8-1": "The URL the consumer has used to access the service", "5-1": "The user agent type for which the transaction was processed for", "4-1": "The verification method that was used for the payment", "9-1": "Unique 60 character ID displayed to the consumer", "11-1": "Timestamp of when the page was served to the consumer", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-2": "ABC123", "4-2": "**SMS** - SMS marketing message link used\n**MobileData** - 3G/ 4G data verification\n**MT Link **- Consumer entered MSISDN\n**IVR Call** - Consumer called IVR line\n**MO Msg** - Consumer texted keyword\n**Repeat **- Recurring payment", "5-2": "Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10.", "8-2": "http://angelfish1.impulsepay.com/yourpage", "9-2": "754YUCSJO-D09EE0E7-AB97-4A21-9T50-AB62967D0F54FFC412136342A3", "11-2": "YYYY-MM-DD HH:MM:SS", "2-0": "Note", "2-1": "Merchant specific parameters", "2-2": "Param1#Param2#Param3", "3-0": "AffiliateID", "3-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "3-2": "A=1;B=2", "6-0": "URLReferer", "6-1": "The URL referrer or SMS message text used to access service (when known)", "6-2": "http://www.google.com", "10-0": "TemplateName", "10-1": "The saved name of the template displayed to the consumer", "10-2": "\"MobileB1\"", "7-0": "RefererIP", "7-1": "IP address header information of the user" }, "cols": 3, "rows": 12 } [/block] Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. Due to the volume of hits, ImpulsePay will not retry these notifications in the event of a merchant failure, however the same information is available on the detailed dashboard.
{"__v":6,"_id":"55351fe549945b0d00cb4ddc","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"This alert will be sent once the PaymentPage has determined which verification type the consumer will use, dependant on their data connection. This alert sends details on the verification method used and further details about the interaction with the PaymentPage. \n\nMerchants can use this alert by providing a URL in the Config page on the Dashboard.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Parameters\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameters\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"PWID\",\n    \"1-0\": \"CampaignID\",\n    \"2-0\": \"Note\",\n    \"3-0\": \"AffiliateID\",\n    \"4-0\": \"MSISDN\",\n    \"5-0\": \"MSISDNType\",\n    \"6-0\": \"Operator\",\n    \"7-0\": \"ReferrerIP\",\n    \"0-1\": \"A 75 character unique ID for this transaction.\",\n    \"1-1\": \"The CampaignID specified for this request\",\n    \"2-1\": \"The merchant can use the note for passing custom parameters through. These will be returned to the merchant in the billing notification. This can be a maximum of 250 characters.\",\n    \"3-1\": \"Used to define multiple custom variables (using '-' as a delimiter) to capture custom affiliates tracking data. For example, AffID=AA-BB will result ‘AA’ and ‘BB’ parameters being stored for this request and returned to the merchant. The maximum Affiliate data that will be stored is limited to 250 characters.\",\n    \"4-1\": \"The MSISDN or Alias for the consumer\",\n    \"5-1\": \"Flag to specify if this is a MSISDN or ALIAS being passed.\",\n    \"6-1\": \"The consumers mobile operator\",\n    \"7-1\": \"The IP address of the consumer\",\n    \"0-2\": \"201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8\",\n    \"1-2\": \"ABC123\",\n    \"2-2\": \"Param1#Param2#Param3\",\n    \"3-2\": \"A=1;B=2\",\n    \"4-2\": \"447123123123\",\n    \"5-2\": \"MSISDN | ALIAS\",\n    \"6-2\": \"o2_uk,\\norange_uk,\\nthree_uk,\\ntmobile_uk,\\nvirgin_uk,\\nvodafone_uk\",\n    \"7-2\": \"0.0.0.0\"\n  },\n  \"cols\": 3,\n  \"rows\": 8\n}\n[/block]\nMerchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.","category":"564b0edd1a8e610d006bfce1","createdAt":"2015-04-20T15:48:53.471Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":3,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"verification-method-alert","sync_unique":"","title":"Notify 3G Connection","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Notify 3G Connection


This alert will be sent once the PaymentPage has determined which verification type the consumer will use, dependant on their data connection. This alert sends details on the verification method used and further details about the interaction with the PaymentPage. Merchants can use this alert by providing a URL in the Config page on the Dashboard. [block:api-header] { "type": "basic", "title": "Parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameters", "h-1": "Description", "h-2": "Example", "0-0": "PWID", "1-0": "CampaignID", "2-0": "Note", "3-0": "AffiliateID", "4-0": "MSISDN", "5-0": "MSISDNType", "6-0": "Operator", "7-0": "ReferrerIP", "0-1": "A 75 character unique ID for this transaction.", "1-1": "The CampaignID specified for this request", "2-1": "The merchant can use the note for passing custom parameters through. These will be returned to the merchant in the billing notification. This can be a maximum of 250 characters.", "3-1": "Used to define multiple custom variables (using '-' as a delimiter) to capture custom affiliates tracking data. For example, AffID=AA-BB will result ‘AA’ and ‘BB’ parameters being stored for this request and returned to the merchant. The maximum Affiliate data that will be stored is limited to 250 characters.", "4-1": "The MSISDN or Alias for the consumer", "5-1": "Flag to specify if this is a MSISDN or ALIAS being passed.", "6-1": "The consumers mobile operator", "7-1": "The IP address of the consumer", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-2": "ABC123", "2-2": "Param1#Param2#Param3", "3-2": "A=1;B=2", "4-2": "447123123123", "5-2": "MSISDN | ALIAS", "6-2": "o2_uk,\norange_uk,\nthree_uk,\ntmobile_uk,\nvirgin_uk,\nvodafone_uk", "7-2": "0.0.0.0" }, "cols": 3, "rows": 8 } [/block] Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.
This alert will be sent once the PaymentPage has determined which verification type the consumer will use, dependant on their data connection. This alert sends details on the verification method used and further details about the interaction with the PaymentPage. Merchants can use this alert by providing a URL in the Config page on the Dashboard. [block:api-header] { "type": "basic", "title": "Parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameters", "h-1": "Description", "h-2": "Example", "0-0": "PWID", "1-0": "CampaignID", "2-0": "Note", "3-0": "AffiliateID", "4-0": "MSISDN", "5-0": "MSISDNType", "6-0": "Operator", "7-0": "ReferrerIP", "0-1": "A 75 character unique ID for this transaction.", "1-1": "The CampaignID specified for this request", "2-1": "The merchant can use the note for passing custom parameters through. These will be returned to the merchant in the billing notification. This can be a maximum of 250 characters.", "3-1": "Used to define multiple custom variables (using '-' as a delimiter) to capture custom affiliates tracking data. For example, AffID=AA-BB will result ‘AA’ and ‘BB’ parameters being stored for this request and returned to the merchant. The maximum Affiliate data that will be stored is limited to 250 characters.", "4-1": "The MSISDN or Alias for the consumer", "5-1": "Flag to specify if this is a MSISDN or ALIAS being passed.", "6-1": "The consumers mobile operator", "7-1": "The IP address of the consumer", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-2": "ABC123", "2-2": "Param1#Param2#Param3", "3-2": "A=1;B=2", "4-2": "447123123123", "5-2": "MSISDN | ALIAS", "6-2": "o2_uk,\norange_uk,\nthree_uk,\ntmobile_uk,\nvirgin_uk,\nvodafone_uk", "7-2": "0.0.0.0" }, "cols": 3, "rows": 8 } [/block] Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.
{"__v":14,"_id":"5534da0749945b0d00cb4d6c","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"This API can be used to notify the merchant each time a consumer presses the initial button. To activate it, simply enter the URL into the Config page on the dashboard.\n[block:api-header]\n{\n  \"type\": \"basic\"\n}\n[/block]\nThe following parameters are returned on each notification to the given URL\n[block:parameters]\n{\n  \"data\": {\n    \"0-0\": \"PWID\",\n    \"1-0\": \"CampaignID\",\n    \"4-0\": \"FlowType\",\n    \"5-0\": \"Useragent\",\n    \"7-0\": \"AccessURL\",\n    \"8-0\": \"TemplateID\",\n    \"10-0\": \"TimeToClick\",\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-1\": \"A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.\",\n    \"1-1\": \"The CampaignID specified for this request\",\n    \"7-1\": \"The URL the consumer has used to access the service\",\n    \"5-1\": \"The user agent type for which the transaction was processed for\",\n    \"4-1\": \"The verification method that was used for the payment\",\n    \"8-1\": \"Unique 60 character ID displayed to the consumer\",\n    \"10-1\": \"Timestamp (in seconds) of when the initial button was clicked by the consumer\",\n    \"0-2\": \"201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8\",\n    \"1-2\": \"ABC123\",\n    \"4-2\": \"**SMS** - SMS marketing message link used\\n**MobileData** - 3G/ 4G data verification\\n**MT Link **- Consumer entered MSISDN\\n**IVR Call** - Consumer called IVR line\\n**MO Msg** - Consumer texted keyword\\n**Repeat **- Recurring payment\",\n    \"5-2\": \"Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10.\",\n    \"7-2\": \"http://angelfish1.impulsepay.com/yourpage\",\n    \"8-2\": \"754YUCSJO-D09EE0E7-AB97-4A21-9T50-AB62967D0F54FFC412136342A3\",\n    \"10-2\": \"12\",\n    \"2-0\": \"Note\",\n    \"2-1\": \"Merchant specific parameters\",\n    \"2-2\": \"Param1#Param2#Param3\",\n    \"3-0\": \"AffiliateID\",\n    \"3-1\": \"Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.\",\n    \"3-2\": \"A=1;B=2\",\n    \"6-0\": \"URLReferer\",\n    \"6-1\": \"URL referrer, SMS message text used to access service by (when known)\",\n    \"6-2\": \"http://www.google.com\",\n    \"9-0\": \"TemplateName\",\n    \"9-1\": \"The saved name of the template displayed to the consumer\",\n    \"9-2\": \"\\\"MobileB1\\\"\",\n    \"11-0\": \"FriendlyName\",\n    \"11-1\": \"FriendlyName that was passed in through the button on the Paywall engine.\",\n    \"11-2\": \"Access24Hrs3\",\n    \"12-0\": \"Logged\",\n    \"12-1\": \"The Timestamp for when the button was clicked.\",\n    \"12-2\": \"1433942082\"\n  },\n  \"cols\": 3,\n  \"rows\": 13\n}\n[/block]\nMerchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.","category":"564b0edd1a8e610d006bfce1","createdAt":"2015-04-20T10:50:47.373Z","excerpt":"This API allows the merchant to be informed each time their purchase button is pressed","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":4,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"first-click-api","sync_unique":"","title":"Notify First Click","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Notify First Click

This API allows the merchant to be informed each time their purchase button is pressed

This API can be used to notify the merchant each time a consumer presses the initial button. To activate it, simply enter the URL into the Config page on the dashboard. [block:api-header] { "type": "basic" } [/block] The following parameters are returned on each notification to the given URL [block:parameters] { "data": { "0-0": "PWID", "1-0": "CampaignID", "4-0": "FlowType", "5-0": "Useragent", "7-0": "AccessURL", "8-0": "TemplateID", "10-0": "TimeToClick", "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-1": "A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.", "1-1": "The CampaignID specified for this request", "7-1": "The URL the consumer has used to access the service", "5-1": "The user agent type for which the transaction was processed for", "4-1": "The verification method that was used for the payment", "8-1": "Unique 60 character ID displayed to the consumer", "10-1": "Timestamp (in seconds) of when the initial button was clicked by the consumer", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-2": "ABC123", "4-2": "**SMS** - SMS marketing message link used\n**MobileData** - 3G/ 4G data verification\n**MT Link **- Consumer entered MSISDN\n**IVR Call** - Consumer called IVR line\n**MO Msg** - Consumer texted keyword\n**Repeat **- Recurring payment", "5-2": "Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10.", "7-2": "http://angelfish1.impulsepay.com/yourpage", "8-2": "754YUCSJO-D09EE0E7-AB97-4A21-9T50-AB62967D0F54FFC412136342A3", "10-2": "12", "2-0": "Note", "2-1": "Merchant specific parameters", "2-2": "Param1#Param2#Param3", "3-0": "AffiliateID", "3-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "3-2": "A=1;B=2", "6-0": "URLReferer", "6-1": "URL referrer, SMS message text used to access service by (when known)", "6-2": "http://www.google.com", "9-0": "TemplateName", "9-1": "The saved name of the template displayed to the consumer", "9-2": "\"MobileB1\"", "11-0": "FriendlyName", "11-1": "FriendlyName that was passed in through the button on the Paywall engine.", "11-2": "Access24Hrs3", "12-0": "Logged", "12-1": "The Timestamp for when the button was clicked.", "12-2": "1433942082" }, "cols": 3, "rows": 13 } [/block] Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.
This API can be used to notify the merchant each time a consumer presses the initial button. To activate it, simply enter the URL into the Config page on the dashboard. [block:api-header] { "type": "basic" } [/block] The following parameters are returned on each notification to the given URL [block:parameters] { "data": { "0-0": "PWID", "1-0": "CampaignID", "4-0": "FlowType", "5-0": "Useragent", "7-0": "AccessURL", "8-0": "TemplateID", "10-0": "TimeToClick", "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-1": "A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.", "1-1": "The CampaignID specified for this request", "7-1": "The URL the consumer has used to access the service", "5-1": "The user agent type for which the transaction was processed for", "4-1": "The verification method that was used for the payment", "8-1": "Unique 60 character ID displayed to the consumer", "10-1": "Timestamp (in seconds) of when the initial button was clicked by the consumer", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-2": "ABC123", "4-2": "**SMS** - SMS marketing message link used\n**MobileData** - 3G/ 4G data verification\n**MT Link **- Consumer entered MSISDN\n**IVR Call** - Consumer called IVR line\n**MO Msg** - Consumer texted keyword\n**Repeat **- Recurring payment", "5-2": "Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10.", "7-2": "http://angelfish1.impulsepay.com/yourpage", "8-2": "754YUCSJO-D09EE0E7-AB97-4A21-9T50-AB62967D0F54FFC412136342A3", "10-2": "12", "2-0": "Note", "2-1": "Merchant specific parameters", "2-2": "Param1#Param2#Param3", "3-0": "AffiliateID", "3-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "3-2": "A=1;B=2", "6-0": "URLReferer", "6-1": "URL referrer, SMS message text used to access service by (when known)", "6-2": "http://www.google.com", "9-0": "TemplateName", "9-1": "The saved name of the template displayed to the consumer", "9-2": "\"MobileB1\"", "11-0": "FriendlyName", "11-1": "FriendlyName that was passed in through the button on the Paywall engine.", "11-2": "Access24Hrs3", "12-0": "Logged", "12-1": "The Timestamp for when the button was clicked.", "12-2": "1433942082" }, "cols": 3, "rows": 13 } [/block] Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.
{"__v":0,"_id":"552fa2c1f99ae00d00e0547e","api":{"auth":"required","examples":{"codes":[{"name":"","code":"http://bill.impulsepay.com/CheckBlacklist?MSISDN=447701234567&Key=0","language":"http"}]},"params":[{"_id":"552f8d2db09eaf0d008deb41","required":false,"desc":"The consumer's MSISDN to check against the blacklist","default":"447701234567","type":"int","name":"MSISDN","in":"body"},{"_id":"552f8d94633a5b0d00e99dbb","required":false,"desc":"The merchant's API access key","default":"","type":"mixed","name":"Key","in":"body"}],"results":{"codes":[{"status":200,"language":"json","code":"{Entry: Accept}","name":""},{"status":200,"language":"json","code":"{Entry: Deny}"}]},"settings":"","url":"http://bill.impulsepay.com/CheckBlacklist?"},"body":"This API allows the merchant to quickly determine if a consumer has been added to the ImpulsePay blacklist. \n\nThis API is useful for Customer Care situations where an operative needs to check if a user has been blocked by ImpulsePay. \n\nImpulsePay recommends that merchants maintain their own blacklist record, rather than relying on ImpulsePay. This is because merchants who use multiple services are likely to receive opt-out requests from all their services, whereas ImpulsePay will only maintain a list of users for services operated by ImpulsePay.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"API parameters\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"MSISDN\",\n    \"0-1\": \"The consumer's MSISDN to be checked against the blacklist.\",\n    \"0-2\": \"\\\"44712345678\\\"\",\n    \"2-0\": \"Key\",\n    \"2-1\": \"The merchant's API access key.\",\n    \"2-2\": \"\\\"ABC123\\\"\",\n    \"1-0\": \"MSISDNType\",\n    \"1-1\": \"Flag to specify if this is a MSISDN or ALIAS being passed\",\n    \"1-2\": \"MSISDN | ALIAS\"\n  },\n  \"cols\": 3,\n  \"rows\": 3\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Example request\"\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://bill.impulsepay.com/CheckBlacklist?MSISDN=&Key=\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Responses\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Response\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"ACCEPT\",\n    \"1-0\": \"DENY\",\n    \"0-1\": \"The consumer's MSISDN is not on the blacklist and the payment can be accepted.\",\n    \"1-1\": \"The consumer's MSISDN is present on the blacklist and the payment will be denied.\"\n  },\n  \"cols\": 2,\n  \"rows\": 2\n}\n[/block]","category":"564b0ea41a8e610d006bfce0","createdAt":"2015-04-16T11:53:37.137Z","editedParams":true,"editedParams2":true,"excerpt":"To check if a consumer's MSISDN is blacklisted by ImpulsePay, use the following API.","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":0,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"check-blacklist-api-1","sync_unique":"","title":"Query Blacklist API","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Query Blacklist API

To check if a consumer's MSISDN is blacklisted by ImpulsePay, use the following API.

This API allows the merchant to quickly determine if a consumer has been added to the ImpulsePay blacklist. This API is useful for Customer Care situations where an operative needs to check if a user has been blocked by ImpulsePay. ImpulsePay recommends that merchants maintain their own blacklist record, rather than relying on ImpulsePay. This is because merchants who use multiple services are likely to receive opt-out requests from all their services, whereas ImpulsePay will only maintain a list of users for services operated by ImpulsePay. [block:api-header] { "type": "basic", "title": "API parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "MSISDN", "0-1": "The consumer's MSISDN to be checked against the blacklist.", "0-2": "\"44712345678\"", "2-0": "Key", "2-1": "The merchant's API access key.", "2-2": "\"ABC123\"", "1-0": "MSISDNType", "1-1": "Flag to specify if this is a MSISDN or ALIAS being passed", "1-2": "MSISDN | ALIAS" }, "cols": 3, "rows": 3 } [/block] [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/CheckBlacklist?MSISDN=&Key=", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] [block:parameters] { "data": { "h-0": "Response", "h-1": "Description", "0-0": "ACCEPT", "1-0": "DENY", "0-1": "The consumer's MSISDN is not on the blacklist and the payment can be accepted.", "1-1": "The consumer's MSISDN is present on the blacklist and the payment will be denied." }, "cols": 2, "rows": 2 } [/block]
This API allows the merchant to quickly determine if a consumer has been added to the ImpulsePay blacklist. This API is useful for Customer Care situations where an operative needs to check if a user has been blocked by ImpulsePay. ImpulsePay recommends that merchants maintain their own blacklist record, rather than relying on ImpulsePay. This is because merchants who use multiple services are likely to receive opt-out requests from all their services, whereas ImpulsePay will only maintain a list of users for services operated by ImpulsePay. [block:api-header] { "type": "basic", "title": "API parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "MSISDN", "0-1": "The consumer's MSISDN to be checked against the blacklist.", "0-2": "\"44712345678\"", "2-0": "Key", "2-1": "The merchant's API access key.", "2-2": "\"ABC123\"", "1-0": "MSISDNType", "1-1": "Flag to specify if this is a MSISDN or ALIAS being passed", "1-2": "MSISDN | ALIAS" }, "cols": 3, "rows": 3 } [/block] [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/CheckBlacklist?MSISDN=&Key=", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] [block:parameters] { "data": { "h-0": "Response", "h-1": "Description", "0-0": "ACCEPT", "1-0": "DENY", "0-1": "The consumer's MSISDN is not on the blacklist and the payment can be accepted.", "1-1": "The consumer's MSISDN is present on the blacklist and the payment will be denied." }, "cols": 2, "rows": 2 } [/block]
{"__v":16,"_id":"553113902e11b2190052356c","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"This API allows merchants to prevent blacklisted users from purchasing. \n\nMerchants provide a URL that is called by ImpulsePay after a consumer has consented to make a purchase, but before they are billed. \n\nThis allows the merchant to receive the parameters below, check these against their blacklist and block a consumer by returning the appropriate response to ImpulsePay. The user can therefore be prevented from making a purchase and instead will be directed to the payment failure page with a 209 status.\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameters\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Value\",\n    \"1-0\": \"CampaignID\",\n    \"3-0\": \"MSISDNType\",\n    \"1-1\": \"The CampaignID specified for this request\",\n    \"3-1\": \"Flag to specify if this is a MSISDN or ALIAS being passed.\",\n    \"3-2\": \"MSISDN | ALIAS\",\n    \"1-2\": \"ABC123\",\n    \"0-0\": \"PWID\",\n    \"0-1\": \"A 75 character unique ID for this transaction.\",\n    \"0-2\": \"201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8\",\n    \"2-0\": \"MSISDN\",\n    \"2-1\": \"The MSISDN or Alias for the consumer\",\n    \"2-2\": \"447123123123\",\n    \"4-0\": \"Note\",\n    \"5-0\": \"AffiliateID\",\n    \"6-0\": \"ReferrerURL\",\n    \"7-0\": \"Useragent\",\n    \"8-0\": \"FlowMethod\",\n    \"9-0\": \"FlowType\",\n    \"10-0\": \"Operator\",\n    \"4-1\": \"Merchant specific parameters\",\n    \"4-2\": \"Param1#Param2#Param3\",\n    \"5-1\": \"Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.\",\n    \"5-2\": \"A=1;B=2\",\n    \"6-1\": \"The URL referrer or SMS message text used to access service (when known)\",\n    \"6-2\": \"http://www.google.com\",\n    \"7-1\": \"The user agent type for which the transaction was processed for\",\n    \"8-1\": \"The device type used for this transaction.\",\n    \"9-1\": \"The verification method that was used for the payment\",\n    \"10-1\": \"The consumers mobile operator.\",\n    \"8-2\": \"Desktop, \\nMobile, \\niPad, \\niPhone, \\nAndroid\",\n    \"9-2\": \"**SMS** - SMS marketing message link used\\n**MobileData** - 3G/ 4G data verification\\n**MT Link **- Consumer entered MSISDN\\n**IVR Call** - Consumer called IVR line\\n**MO Msg** - Consumer texted keyword\\n**Repeat **- Recurring payment\",\n    \"10-2\": \"o2_uk,\\norange_uk,\\nthree_uk,\\ntmobile_uk,\\nvirgin_uk,\\nvodafone_uk\",\n    \"7-2\": \"Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10.\"\n  },\n  \"cols\": 3,\n  \"rows\": 11\n}\n[/block]\nMerchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request.\n\nExpected response from merchant:\n[block:parameters]\n{\n  \"data\": {\n    \"0-0\": \"ACCEPT\",\n    \"1-0\": \"DENY\",\n    \"0-1\": \"Allow the purchase to proceed\",\n    \"1-1\": \"Block the user from making a purchase\",\n    \"h-0\": \"Value\",\n    \"h-1\": \"Description\"\n  },\n  \"cols\": 2,\n  \"rows\": 2\n}\n[/block]\nIn the event of a failure or unexpected response, the purchase will proceed.","category":"564b0ea41a8e610d006bfce0","createdAt":"2015-04-17T14:07:12.679Z","excerpt":"Allows the merchant to prevent a charge before purchase for certain users","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":1,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"allowpurchase","sync_unique":"","title":"Pre-Purchase Blacklist Check","type":"basic","updates":[],"user":"54eb3aaedf7add210007b26a","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Pre-Purchase Blacklist Check

Allows the merchant to prevent a charge before purchase for certain users

This API allows merchants to prevent blacklisted users from purchasing. Merchants provide a URL that is called by ImpulsePay after a consumer has consented to make a purchase, but before they are billed. This allows the merchant to receive the parameters below, check these against their blacklist and block a consumer by returning the appropriate response to ImpulsePay. The user can therefore be prevented from making a purchase and instead will be directed to the payment failure page with a 209 status. [block:parameters] { "data": { "h-0": "Parameters", "h-1": "Description", "h-2": "Value", "1-0": "CampaignID", "3-0": "MSISDNType", "1-1": "The CampaignID specified for this request", "3-1": "Flag to specify if this is a MSISDN or ALIAS being passed.", "3-2": "MSISDN | ALIAS", "1-2": "ABC123", "0-0": "PWID", "0-1": "A 75 character unique ID for this transaction.", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "2-0": "MSISDN", "2-1": "The MSISDN or Alias for the consumer", "2-2": "447123123123", "4-0": "Note", "5-0": "AffiliateID", "6-0": "ReferrerURL", "7-0": "Useragent", "8-0": "FlowMethod", "9-0": "FlowType", "10-0": "Operator", "4-1": "Merchant specific parameters", "4-2": "Param1#Param2#Param3", "5-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "5-2": "A=1;B=2", "6-1": "The URL referrer or SMS message text used to access service (when known)", "6-2": "http://www.google.com", "7-1": "The user agent type for which the transaction was processed for", "8-1": "The device type used for this transaction.", "9-1": "The verification method that was used for the payment", "10-1": "The consumers mobile operator.", "8-2": "Desktop, \nMobile, \niPad, \niPhone, \nAndroid", "9-2": "**SMS** - SMS marketing message link used\n**MobileData** - 3G/ 4G data verification\n**MT Link **- Consumer entered MSISDN\n**IVR Call** - Consumer called IVR line\n**MO Msg** - Consumer texted keyword\n**Repeat **- Recurring payment", "10-2": "o2_uk,\norange_uk,\nthree_uk,\ntmobile_uk,\nvirgin_uk,\nvodafone_uk", "7-2": "Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10." }, "cols": 3, "rows": 11 } [/block] Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. Expected response from merchant: [block:parameters] { "data": { "0-0": "ACCEPT", "1-0": "DENY", "0-1": "Allow the purchase to proceed", "1-1": "Block the user from making a purchase", "h-0": "Value", "h-1": "Description" }, "cols": 2, "rows": 2 } [/block] In the event of a failure or unexpected response, the purchase will proceed.
This API allows merchants to prevent blacklisted users from purchasing. Merchants provide a URL that is called by ImpulsePay after a consumer has consented to make a purchase, but before they are billed. This allows the merchant to receive the parameters below, check these against their blacklist and block a consumer by returning the appropriate response to ImpulsePay. The user can therefore be prevented from making a purchase and instead will be directed to the payment failure page with a 209 status. [block:parameters] { "data": { "h-0": "Parameters", "h-1": "Description", "h-2": "Value", "1-0": "CampaignID", "3-0": "MSISDNType", "1-1": "The CampaignID specified for this request", "3-1": "Flag to specify if this is a MSISDN or ALIAS being passed.", "3-2": "MSISDN | ALIAS", "1-2": "ABC123", "0-0": "PWID", "0-1": "A 75 character unique ID for this transaction.", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "2-0": "MSISDN", "2-1": "The MSISDN or Alias for the consumer", "2-2": "447123123123", "4-0": "Note", "5-0": "AffiliateID", "6-0": "ReferrerURL", "7-0": "Useragent", "8-0": "FlowMethod", "9-0": "FlowType", "10-0": "Operator", "4-1": "Merchant specific parameters", "4-2": "Param1#Param2#Param3", "5-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "5-2": "A=1;B=2", "6-1": "The URL referrer or SMS message text used to access service (when known)", "6-2": "http://www.google.com", "7-1": "The user agent type for which the transaction was processed for", "8-1": "The device type used for this transaction.", "9-1": "The verification method that was used for the payment", "10-1": "The consumers mobile operator.", "8-2": "Desktop, \nMobile, \niPad, \niPhone, \nAndroid", "9-2": "**SMS** - SMS marketing message link used\n**MobileData** - 3G/ 4G data verification\n**MT Link **- Consumer entered MSISDN\n**IVR Call** - Consumer called IVR line\n**MO Msg** - Consumer texted keyword\n**Repeat **- Recurring payment", "10-2": "o2_uk,\norange_uk,\nthree_uk,\ntmobile_uk,\nvirgin_uk,\nvodafone_uk", "7-2": "Mozilla/5.0 (Linux; Android 4.4.2; C6603 Build/10." }, "cols": 3, "rows": 11 } [/block] Merchants can append their own static parameters to the URL when adding it to the dashboard. These parameters will then be included in the appropriate callback request. Expected response from merchant: [block:parameters] { "data": { "0-0": "ACCEPT", "1-0": "DENY", "0-1": "Allow the purchase to proceed", "1-1": "Block the user from making a purchase", "h-0": "Value", "h-1": "Description" }, "cols": 2, "rows": 2 } [/block] In the event of a failure or unexpected response, the purchase will proceed.
{"__v":8,"_id":"552e307e06a32a0d009c2eec","api":{"auth":"required","examples":{"codes":[{"language":"http","code":"http://bill.impulsepay.com/CheckAccess?AccountID=&MSISDNType=&MSISDN=&FriendlyName=&Key=&Extended=","name":""}]},"params":[{"_id":"552f8609633a5b0d00e99db6","required":false,"desc":"The merchant's account ID","default":"","type":"string","name":"AccountID","in":"body"},{"_id":"552f8609633a5b0d00e99db5","required":false,"desc":"MSISDNType","default":"","type":"string","name":"MSISDNType","in":"body"},{"_id":"552f8609633a5b0d00e99db4","required":false,"desc":"The consumers MSISDN or MSISDNalias","default":"","type":"int","name":"MSISDN","in":"body"},{"_id":"552f8609633a5b0d00e99db3","required":false,"desc":"","default":"","type":"string","name":"FriendlyName","in":"body"},{"_id":"552f8609633a5b0d00e99db2","required":false,"desc":"The merchant's API access key","default":"","type":"mixed","name":"Key","in":"body"},{"_id":"552f8609633a5b0d00e99db1","required":false,"desc":"Set Y to receive timestamp along with access parameter","default":"Y or N","type":"string","name":"Extended","in":"body"}],"results":{"codes":[{"name":"DENY","code":"{ACCESS : DENY}","language":"json","status":200},{"name":"ALLOW","status":200,"language":"text","code":"{ACCESS : DENY}"},{"status":200,"name":"Extended","language":"json","code":"{ACCESS : ALLOW, EXPIRES: TIMESTAMP}"}]},"url":"http://bill.impulsepay.com/CheckAccess?"},"body":"Merchants can use the Check access API to confirm whether a consumer has valid access to a service. Merchants can also get extended response parameters from this API, which include a timestamp of when the consumer's access expires. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"API parameters\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"MSISDNType\",\n    \"1-0\": \"MSISDN\",\n    \"2-0\": \"FriendlyName\",\n    \"3-0\": \"Key\",\n    \"4-0\": \"Extended\",\n    \"0-1\": \"The type of number used for the MSISDN field.\",\n    \"1-1\": \"The consumers MSISDN or MSISDNalias\",\n    \"2-1\": \"The service name given in the purchase button parameters\",\n    \"3-1\": \"The merchant's API access key\",\n    \"4-1\": \"Set as Y to receive access expiry timestamp along with access parameter\",\n    \"h-2\": \"Example\",\n    \"0-2\": \"MSISDN |\\nMSISDNalias\",\n    \"1-2\": \"447712345678\",\n    \"2-2\": \"Service A1\",\n    \"3-2\": \"abc123\",\n    \"4-2\": \"Y\"\n  },\n  \"cols\": 3,\n  \"rows\": 5\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Example request\"\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://bill.impulsepay.com/CheckAccess?Key=&MSISDNType=&MSISDN=&FriendlyName=ServiceA&Key=&Extended=\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Responses\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Response Given\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"DENY\",\n    \"0-1\": \"The consumer does not have valid paid access to the service.\",\n    \"1-0\": \"ALLOW\",\n    \"1-1\": \"The consumer has valid paid access to the service.\",\n    \"2-0\": \"INVALID\",\n    \"2-1\": \"The request is not formatted correctly.\"\n  },\n  \"cols\": 2,\n  \"rows\": 3\n}\n[/block]\nIf Extended = Y then the following is returned via a JSON object:\n[block:parameters]\n{\n  \"data\": {\n    \"0-0\": \"Action\",\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Values\",\n    \"0-2\": \"ALLOW | DENY\",\n    \"0-1\": \"The action for this request\",\n    \"1-0\": \"StartAt\",\n    \"2-0\": \"AccessPeriod\",\n    \"3-0\": \"AccessIncrement\",\n    \"4-0\": \"Expires\",\n    \"4-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"1-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"2-2\": \"Int\",\n    \"3-2\": \"Minute, Hour, Day, Week, Month\",\n    \"1-1\": \"The timestamp for when access started\",\n    \"2-1\": \"The unit of time for the access length\",\n    \"3-1\": \"The unit of access\",\n    \"4-1\": \"The timestamp for when access will expire\"\n  },\n  \"cols\": 3,\n  \"rows\": 5\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"URL Key\",\n  \"body\": \"Please contact ImpulsePay to obtain your account key.\",\n  \"sidebar\": true\n}\n[/block]","category":"564b0ea41a8e610d006bfce0","createdAt":"2015-04-15T09:33:50.326Z","editedParams":true,"editedParams2":true,"excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":2,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"api-calls","sync_unique":"","title":"Check Access API","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Check Access API


Merchants can use the Check access API to confirm whether a consumer has valid access to a service. Merchants can also get extended response parameters from this API, which include a timestamp of when the consumer's access expires. [block:api-header] { "type": "basic", "title": "API parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "MSISDNType", "1-0": "MSISDN", "2-0": "FriendlyName", "3-0": "Key", "4-0": "Extended", "0-1": "The type of number used for the MSISDN field.", "1-1": "The consumers MSISDN or MSISDNalias", "2-1": "The service name given in the purchase button parameters", "3-1": "The merchant's API access key", "4-1": "Set as Y to receive access expiry timestamp along with access parameter", "h-2": "Example", "0-2": "MSISDN |\nMSISDNalias", "1-2": "447712345678", "2-2": "Service A1", "3-2": "abc123", "4-2": "Y" }, "cols": 3, "rows": 5 } [/block] [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/CheckAccess?Key=&MSISDNType=&MSISDN=&FriendlyName=ServiceA&Key=&Extended=", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] [block:parameters] { "data": { "h-0": "Response Given", "h-1": "Description", "0-0": "DENY", "0-1": "The consumer does not have valid paid access to the service.", "1-0": "ALLOW", "1-1": "The consumer has valid paid access to the service.", "2-0": "INVALID", "2-1": "The request is not formatted correctly." }, "cols": 2, "rows": 3 } [/block] If Extended = Y then the following is returned via a JSON object: [block:parameters] { "data": { "0-0": "Action", "h-0": "Parameter", "h-1": "Description", "h-2": "Values", "0-2": "ALLOW | DENY", "0-1": "The action for this request", "1-0": "StartAt", "2-0": "AccessPeriod", "3-0": "AccessIncrement", "4-0": "Expires", "4-2": "YYYY-MM-DD HH:MM:SS", "1-2": "YYYY-MM-DD HH:MM:SS", "2-2": "Int", "3-2": "Minute, Hour, Day, Week, Month", "1-1": "The timestamp for when access started", "2-1": "The unit of time for the access length", "3-1": "The unit of access", "4-1": "The timestamp for when access will expire" }, "cols": 3, "rows": 5 } [/block] [block:callout] { "type": "info", "title": "URL Key", "body": "Please contact ImpulsePay to obtain your account key.", "sidebar": true } [/block]
Merchants can use the Check access API to confirm whether a consumer has valid access to a service. Merchants can also get extended response parameters from this API, which include a timestamp of when the consumer's access expires. [block:api-header] { "type": "basic", "title": "API parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "MSISDNType", "1-0": "MSISDN", "2-0": "FriendlyName", "3-0": "Key", "4-0": "Extended", "0-1": "The type of number used for the MSISDN field.", "1-1": "The consumers MSISDN or MSISDNalias", "2-1": "The service name given in the purchase button parameters", "3-1": "The merchant's API access key", "4-1": "Set as Y to receive access expiry timestamp along with access parameter", "h-2": "Example", "0-2": "MSISDN |\nMSISDNalias", "1-2": "447712345678", "2-2": "Service A1", "3-2": "abc123", "4-2": "Y" }, "cols": 3, "rows": 5 } [/block] [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/CheckAccess?Key=&MSISDNType=&MSISDN=&FriendlyName=ServiceA&Key=&Extended=", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] [block:parameters] { "data": { "h-0": "Response Given", "h-1": "Description", "0-0": "DENY", "0-1": "The consumer does not have valid paid access to the service.", "1-0": "ALLOW", "1-1": "The consumer has valid paid access to the service.", "2-0": "INVALID", "2-1": "The request is not formatted correctly." }, "cols": 2, "rows": 3 } [/block] If Extended = Y then the following is returned via a JSON object: [block:parameters] { "data": { "0-0": "Action", "h-0": "Parameter", "h-1": "Description", "h-2": "Values", "0-2": "ALLOW | DENY", "0-1": "The action for this request", "1-0": "StartAt", "2-0": "AccessPeriod", "3-0": "AccessIncrement", "4-0": "Expires", "4-2": "YYYY-MM-DD HH:MM:SS", "1-2": "YYYY-MM-DD HH:MM:SS", "2-2": "Int", "3-2": "Minute, Hour, Day, Week, Month", "1-1": "The timestamp for when access started", "2-1": "The unit of time for the access length", "3-1": "The unit of access", "4-1": "The timestamp for when access will expire" }, "cols": 3, "rows": 5 } [/block] [block:callout] { "type": "info", "title": "URL Key", "body": "Please contact ImpulsePay to obtain your account key.", "sidebar": true } [/block]
{"__v":10,"_id":"55cdfc18950b8e0d00f11ddc","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"This API can be used to detect a user's MSISDNalias so that the consumer can be identified by the merchant before reaching a payment page. \n\nTo use, forward the user to the below URL with the encoded AccountID in the path, and the RouteID in the query string.\n\nThe ReturnURL should contain the location we should forward the user to after the lookup is complete. This should be URLEncoded and should contain any GET params that should be sent with it when we forward the user on.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://secure.impulsepay.com/channel/alias/{EncodedRouteID}/?ReturnURL={ReturnURL}&key={key}&apikey={APIAccessKey}\",\n      \"language\": \"http\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"API Parameters\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"EncodedRouteID\",\n    \"0-1\": \"The merchant's 6 digit accountID base36 encoded\",\n    \"0-2\": \"258k\\n(100100)\",\n    \"1-0\": \"ReturnURL\",\n    \"1-1\": \"The fully url encoded return URL that the consumer will be redirected to once the MSISDNalias has been detected.\",\n    \"1-2\": \"http://merchantdomain.com\",\n    \"3-0\": \"key\",\n    \"3-1\": \"The merchant's API access key, found in the ImpulsePay dashboard.\",\n    \"3-2\": \"0123ABC\",\n    \"2-0\": \"apikey\",\n    \"2-1\": \"A static key, provided by ImpulsePay\",\n    \"2-2\": \"123\"\n  },\n  \"cols\": 3,\n  \"rows\": 4\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Example Request\"\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"secure.impulsepay.com/channel/alias/ldnx?Returnurl=http%3A%2F%2Fexample.net&key=36osmk&apikey=I_eKf1l4MSr4BwOZ4r9x6s==\\n\",\n      \"language\": \"http\",\n      \"name\": \"Request\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Responses\"\n}\n[/block]\nOnce the consumer has been redirected to the API, they will be redirected to the ReturnURL with the following URI encoded parameters in the QueryString: \n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"Alias\",\n    \"0-1\": \"If an Alias has been found for the consumer, the Alias parameter will contain the users MSISDNalias 3DES encryped with the merchant's Timestamp Key (specified in the Route Settings page)\",\n    \"0-2\": \"52TgYIt0AFRcKnomVOPQ5A%3D%3D\",\n    \"1-0\": \"Operator\",\n    \"1-1\": \"The Mobile Operator of the consumer in Impulsepay format\",\n    \"1-2\": \"(o2_uk) 2\\n(orange_uk) 4\\n(three_uk) 8 \\n(tmobile_uk) 16\\n(virgin_uk) 32\\n(vodafone_uk) 64\",\n    \"2-0\": \"GUID\",\n    \"2-1\": \"A unique identifier for this alias lookup. Note that this is unique every time.\",\n    \"2-2\": \"20150819-ALIAS-72ceca4c-6e36-4021-993f-8b3e84d21094\"\n  },\n  \"cols\": 3,\n  \"rows\": 3\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://{ReturnURL}?foo=bar&alias=52TgYIt0AFRcKnomVOPQ5A%3D%3D&operator=8&GUID=20150819-ALIAS-72ceca4c-6e36-4021-993f-8b3e84d21094\",\n      \"language\": \"http\",\n      \"name\": \"Response\"\n    }\n  ]\n}\n[/block]","category":"564b0ea41a8e610d006bfce0","createdAt":"2015-08-14T14:32:56.808Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":3,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"fetch-msisdnalias-api","sync_unique":"","title":"Fetch MSISDNAlias API","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Fetch MSISDNAlias API


This API can be used to detect a user's MSISDNalias so that the consumer can be identified by the merchant before reaching a payment page. To use, forward the user to the below URL with the encoded AccountID in the path, and the RouteID in the query string. The ReturnURL should contain the location we should forward the user to after the lookup is complete. This should be URLEncoded and should contain any GET params that should be sent with it when we forward the user on. [block:code] { "codes": [ { "code": "http://secure.impulsepay.com/channel/alias/{EncodedRouteID}/?ReturnURL={ReturnURL}&key={key}&apikey={APIAccessKey}", "language": "http" } ] } [/block] [block:api-header] { "type": "basic", "title": "API Parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "EncodedRouteID", "0-1": "The merchant's 6 digit accountID base36 encoded", "0-2": "258k\n(100100)", "1-0": "ReturnURL", "1-1": "The fully url encoded return URL that the consumer will be redirected to once the MSISDNalias has been detected.", "1-2": "http://merchantdomain.com", "3-0": "key", "3-1": "The merchant's API access key, found in the ImpulsePay dashboard.", "3-2": "0123ABC", "2-0": "apikey", "2-1": "A static key, provided by ImpulsePay", "2-2": "123" }, "cols": 3, "rows": 4 } [/block] [block:api-header] { "type": "basic", "title": "Example Request" } [/block] [block:code] { "codes": [ { "code": "secure.impulsepay.com/channel/alias/ldnx?Returnurl=http%3A%2F%2Fexample.net&key=36osmk&apikey=I_eKf1l4MSr4BwOZ4r9x6s==\n", "language": "http", "name": "Request" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] Once the consumer has been redirected to the API, they will be redirected to the ReturnURL with the following URI encoded parameters in the QueryString: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "Alias", "0-1": "If an Alias has been found for the consumer, the Alias parameter will contain the users MSISDNalias 3DES encryped with the merchant's Timestamp Key (specified in the Route Settings page)", "0-2": "52TgYIt0AFRcKnomVOPQ5A%3D%3D", "1-0": "Operator", "1-1": "The Mobile Operator of the consumer in Impulsepay format", "1-2": "(o2_uk) 2\n(orange_uk) 4\n(three_uk) 8 \n(tmobile_uk) 16\n(virgin_uk) 32\n(vodafone_uk) 64", "2-0": "GUID", "2-1": "A unique identifier for this alias lookup. Note that this is unique every time.", "2-2": "20150819-ALIAS-72ceca4c-6e36-4021-993f-8b3e84d21094" }, "cols": 3, "rows": 3 } [/block] [block:code] { "codes": [ { "code": "http://{ReturnURL}?foo=bar&alias=52TgYIt0AFRcKnomVOPQ5A%3D%3D&operator=8&GUID=20150819-ALIAS-72ceca4c-6e36-4021-993f-8b3e84d21094", "language": "http", "name": "Response" } ] } [/block]
This API can be used to detect a user's MSISDNalias so that the consumer can be identified by the merchant before reaching a payment page. To use, forward the user to the below URL with the encoded AccountID in the path, and the RouteID in the query string. The ReturnURL should contain the location we should forward the user to after the lookup is complete. This should be URLEncoded and should contain any GET params that should be sent with it when we forward the user on. [block:code] { "codes": [ { "code": "http://secure.impulsepay.com/channel/alias/{EncodedRouteID}/?ReturnURL={ReturnURL}&key={key}&apikey={APIAccessKey}", "language": "http" } ] } [/block] [block:api-header] { "type": "basic", "title": "API Parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "EncodedRouteID", "0-1": "The merchant's 6 digit accountID base36 encoded", "0-2": "258k\n(100100)", "1-0": "ReturnURL", "1-1": "The fully url encoded return URL that the consumer will be redirected to once the MSISDNalias has been detected.", "1-2": "http://merchantdomain.com", "3-0": "key", "3-1": "The merchant's API access key, found in the ImpulsePay dashboard.", "3-2": "0123ABC", "2-0": "apikey", "2-1": "A static key, provided by ImpulsePay", "2-2": "123" }, "cols": 3, "rows": 4 } [/block] [block:api-header] { "type": "basic", "title": "Example Request" } [/block] [block:code] { "codes": [ { "code": "secure.impulsepay.com/channel/alias/ldnx?Returnurl=http%3A%2F%2Fexample.net&key=36osmk&apikey=I_eKf1l4MSr4BwOZ4r9x6s==\n", "language": "http", "name": "Request" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] Once the consumer has been redirected to the API, they will be redirected to the ReturnURL with the following URI encoded parameters in the QueryString: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "Alias", "0-1": "If an Alias has been found for the consumer, the Alias parameter will contain the users MSISDNalias 3DES encryped with the merchant's Timestamp Key (specified in the Route Settings page)", "0-2": "52TgYIt0AFRcKnomVOPQ5A%3D%3D", "1-0": "Operator", "1-1": "The Mobile Operator of the consumer in Impulsepay format", "1-2": "(o2_uk) 2\n(orange_uk) 4\n(three_uk) 8 \n(tmobile_uk) 16\n(virgin_uk) 32\n(vodafone_uk) 64", "2-0": "GUID", "2-1": "A unique identifier for this alias lookup. Note that this is unique every time.", "2-2": "20150819-ALIAS-72ceca4c-6e36-4021-993f-8b3e84d21094" }, "cols": 3, "rows": 3 } [/block] [block:code] { "codes": [ { "code": "http://{ReturnURL}?foo=bar&alias=52TgYIt0AFRcKnomVOPQ5A%3D%3D&operator=8&GUID=20150819-ALIAS-72ceca4c-6e36-4021-993f-8b3e84d21094", "language": "http", "name": "Response" } ] } [/block]
{"__v":12,"_id":"553115942e11b21900523571","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"url":""},"body":"Merchants can use the Cancel recurring payment API to cancel a single recurring payment cycle per request. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"API parameters\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"RPID\",\n    \"0-1\": \"The unique identifier for the recurring payment that the merchant is cancelling.\",\n    \"0-2\": \"201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8\",\n    \"1-0\": \"Key\",\n    \"1-1\": \"The merchant's API access key\",\n    \"1-2\": \"ABC123\"\n  },\n  \"cols\": 3,\n  \"rows\": 2\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Example request\"\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://bill.impulsepay.com/CancelRecurringPayment?RPID=&Key=\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Responses\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Response\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"ACCEPT\",\n    \"1-0\": \"INVALID\",\n    \"0-1\": \"Returned if the RPID has successfully been cancelled\",\n    \"1-1\": \"Returned if the RPID has not been recognised or found in the database. Check formatting conforms to example request and that the RPID exists for the MSISDN.\"\n  },\n  \"cols\": 2,\n  \"rows\": 2\n}\n[/block]","category":"564b0ea41a8e610d006bfce0","createdAt":"2015-04-17T14:15:48.803Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":4,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"remove-rpid-api","sync_unique":"","title":"Cancel RP API","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Cancel RP API


Merchants can use the Cancel recurring payment API to cancel a single recurring payment cycle per request. [block:api-header] { "type": "basic", "title": "API parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "RPID", "0-1": "The unique identifier for the recurring payment that the merchant is cancelling.", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-0": "Key", "1-1": "The merchant's API access key", "1-2": "ABC123" }, "cols": 3, "rows": 2 } [/block] [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/CancelRecurringPayment?RPID=&Key=", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] [block:parameters] { "data": { "h-0": "Response", "h-1": "Description", "0-0": "ACCEPT", "1-0": "INVALID", "0-1": "Returned if the RPID has successfully been cancelled", "1-1": "Returned if the RPID has not been recognised or found in the database. Check formatting conforms to example request and that the RPID exists for the MSISDN." }, "cols": 2, "rows": 2 } [/block]
Merchants can use the Cancel recurring payment API to cancel a single recurring payment cycle per request. [block:api-header] { "type": "basic", "title": "API parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "RPID", "0-1": "The unique identifier for the recurring payment that the merchant is cancelling.", "0-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "1-0": "Key", "1-1": "The merchant's API access key", "1-2": "ABC123" }, "cols": 3, "rows": 2 } [/block] [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/CancelRecurringPayment?RPID=&Key=", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] [block:parameters] { "data": { "h-0": "Response", "h-1": "Description", "0-0": "ACCEPT", "1-0": "INVALID", "0-1": "Returned if the RPID has successfully been cancelled", "1-1": "Returned if the RPID has not been recognised or found in the database. Check formatting conforms to example request and that the RPID exists for the MSISDN." }, "cols": 2, "rows": 2 } [/block]
{"__v":0,"_id":"5703c117d8d0fa0e00de30c2","api":{"settings":"","results":{"codes":[{"language":"text","code":"See extended status codes for response code details"}]},"examples":{"codes":[{"language":"text","code":"http://uk.impulsepay.com/smssend?MSISDN=&MSISDNType=MSISDN&Alert=&Message=hello+world&Sender=test&CampaignID=&Key=key&TransID=&Note=&AffiliateID=&FriendlyName=;","name":"MSISDN Known"},{"name":"Alias Known","language":"text","code":"http://uk.impulsepay.com/smssend?MSISDN=&MSISDNType=Alias&Alert=&Message=hello+world&Sender=test&CampaignID=&Key=key&TransID=&Note=&AffiliateID=&FriendlyName=;"},{"name":"Clickable link for marketing message","language":"text","code":"Merchants can add a clickable link into marketing messages which will take consumers straight to the service site (including on a wifi data connection). \n\nhttp://URL/##SMSLink## "}]},"auth":"required","params":[{"_id":"5530d0b78c108a1900e5a39b","ref":"","required":false,"desc":"The MSISDN the message is being sent to","default":"447712345678","type":"int","name":"MSISDN","in":"body"},{"_id":"5530d0b78c108a1900e5a39a","ref":"","required":false,"desc":"Specifies whether the previous parameter is a MSISDN or Alias","default":"MSISDN or IPAlias","type":"string","name":"MSISDNtype","in":"body"},{"_id":"5530d0b78c108a1900e5a399","ref":"","required":false,"desc":"","default":"","type":"string","name":"Alert","in":"body"},{"_id":"5530d0b78c108a1900e5a398","ref":"","required":false,"desc":"The message text to be sent. Pound signs must be encoded as %C2%A3","default":"\"hello+world\"","type":"string","name":"Message","in":"body"},{"_id":"5530d214c4e7a00d0021c3b2","ref":"","required":false,"desc":"The sender of the message, to go in the From field","default":"\"Test\"","type":"string","name":"Sender","in":"body"},{"_id":"5530d214c4e7a00d0021c3b1","ref":"","required":false,"desc":"","default":"","type":"string","name":"CampaignID","in":"body"},{"_id":"5530d214c4e7a00d0021c3b0","ref":"","required":false,"desc":"The merchant's SMS Send access key","default":"","type":"string","name":"Key","in":"body"},{"_id":"5530d214c4e7a00d0021c3af","ref":"","required":false,"desc":"","default":"","type":"string","name":"TransID","in":"body"},{"_id":"5530d214c4e7a00d0021c3ae","ref":"","required":false,"desc":"","default":"","type":"string","name":"Note","in":"body"},{"_id":"5530d214c4e7a00d0021c3ad","ref":"","required":false,"desc":"","default":"","type":"string","name":"AffiliateID","in":"body"},{"_id":"5530d214c4e7a00d0021c3ac","ref":"","required":false,"desc":"","default":"","type":"string","name":"FriendlyName","in":"body"}],"url":"http://uk.impulsepay.com/smssend?"},"body":"Merchants are able to use the SMS Send API to distribute marketing messages to consumers who have given consent. \n\nWhen the consumer clicks on a marketing link they are taken to the PaymentPage, from which they can continue on to make a purchase. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"API Request parameters\"\n}\n[/block]\nRequests to the SMS Send API should be submitted to the following URL as a GET request.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://sms.impulsepay.com/smssend?\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\nThe following parameters should be included on all requests:\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"MSISDN\",\n    \"0-1\": \"The MSISDN the message is being sent to\",\n    \"0-2\": \"\\\"447712345678\\\"\",\n    \"1-0\": \"MSISDNtype\",\n    \"1-1\": \"Specifies whether the number given in the MSISDN param is a MSISDN or MSISDNalias\",\n    \"1-2\": \"MSISDN or ALIAS\",\n    \"2-0\": \"Alert\",\n    \"3-0\": \"Message\",\n    \"3-1\": \"The message body for the text. This should be a maximum 160 characters.\",\n    \"3-2\": \"hello world\",\n    \"4-0\": \"Sender\",\n    \"4-1\": \"The From field for the message being sent, which should be a maximum of 11 alphanumeric characters.\",\n    \"4-2\": \"Test\",\n    \"5-0\": \"CampaignID\",\n    \"6-0\": \"Key\",\n    \"6-1\": \"The merchant's SMS send API access key, which is provided by ImpulsePay\",\n    \"6-2\": \"\",\n    \"7-0\": \"TransID\",\n    \"7-1\": \"A unique transaction ID generated for each individual message in the YYYYMM format\",\n    \"8-0\": \"Note\",\n    \"8-1\": \"The merchant can use the note for passing custom parameters through. This can be a maximum of 250 characters.\",\n    \"9-0\": \"AffiliateID\",\n    \"2-1\": \"The URL to send the delivery report to. This should be URLEncoded to prevent the request breaking.\",\n    \"2-2\": \"http://www.domain.com/delrpt\",\n    \"5-1\": \"A custom ID used by the merchant to identify different traffic sources running on a service. This can be a maximum of 15 0-9 or A-Z characters only.\",\n    \"5-2\": \"ABC123\",\n    \"7-2\": \"201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8\",\n    \"9-1\": \"The merchant can use this to provide additional affiliate tracking information. The maximum Affiliate data that will be stored is limited to 250 characters.\",\n    \"8-2\": \"Param1#Param2#Param3\",\n    \"9-2\": \"123456789\",\n    \"h-3\": \"Requirement\",\n    \"0-3\": \"Mandatory\",\n    \"1-3\": \"Mandatory\",\n    \"2-3\": \"Mandatory\",\n    \"3-3\": \"Mandatory\",\n    \"4-3\": \"Mandatory\",\n    \"5-3\": \"Mandatory\",\n    \"6-3\": \"Mandatory\",\n    \"7-3\": \"Mandatory\",\n    \"8-3\": \"Optional\",\n    \"9-3\": \"Optional\",\n    \"10-0\": \"SendAt\",\n    \"10-1\": \"The merchant can use this parameter to set a particular time to send the message. If left blank, the message will be sent straight-away.\",\n    \"10-2\": \"yyyy-mm-dd hh:mm\\nurl encoded (e.g 2016-04-05%2013%3A00)\",\n    \"10-3\": \"Optional\",\n    \"11-0\": \"udh\",\n    \"11-1\": \"The merchant can use this value to string long text messages together so they appear concurrently to the user.\",\n    \"11-2\": \"050003000201 \\nSee details below.\",\n    \"11-3\": \"Optional\"\n  },\n  \"cols\": 4,\n  \"rows\": 12\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Joining together messages over 160 characters in length\"\n}\n[/block]\nMerchants are able to join messages that are longer than 160 characters by using the UDH parameter. By including this parameter in the correct format, long messages will appear joined on supported handsets. \n\nThe UDH parameter is a long integer comprised of hexadecimals.The last 6 pairs of digits are the only digits which require configuration. For example, udh=050003**000201** and udh=050003**000202** would be used for a first and second message respectively, sent over two separate requests to the API.  \n\nOf the last 6 pairs of digits, 00 remains the same for both values and serves as an ID for the set of messages. 02 refers to the total amount of messages to be joined, in this case 2. 01 refers to the current message, out of the total messages.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Adding clickable links to messages\"\n}\n[/block]\nTo prevent consumers having to verify their MSISDN when on wifi, a clickable link can be used. This substitutes the link with a secure code that contains the consumers MSISDN. When they proceed on to the PaymentPage, this can be used to identify the consumer and complete a purchase without verifying their MSISDN again.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://bit.ly/##SMSLINK##\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\nTo enable this, merchants need to add a shortened URL link to their payment page followed by the placeholder ##SMSLink##. The secure code is the same length, so won't affect the overall message character count.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Example submission request\"\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://sms.impulsepay.com/smssend?MSISDN=447123456789&Alert=http%3A%2F%2Fdomain.com%2Fdelreport&TransID=201504-4567894143&message=HelloWorld&sender=Example&key=ABC123\",\n      \"language\": \"html\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Submission Response Statuses\"\n}\n[/block]\nOnce a request has been submitted to SMS Send API, it will respond by writing a status code to indicate if the request has been successful or failed. \n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Status Code\",\n    \"h-1\": \"Type\",\n    \"h-2\": \"Description\",\n    \"1-0\": \"010070\",\n    \"1-1\": \"Fail\",\n    \"1-2\": \"Alert URL does not start http://\",\n    \"15-0\": \"010200\",\n    \"15-1\": \"Fail\",\n    \"15-2\": \"MSISDN provided not valid\",\n    \"2-0\": \"010010\",\n    \"2-1\": \"Fail\",\n    \"2-2\": \"TransID contains invalid characters\",\n    \"0-0\": \"140000\",\n    \"0-1\": \"Success\",\n    \"17-0\": \"010999\",\n    \"17-1\": \"Fail\",\n    \"17-2\": \"Duplicate Billing Request\",\n    \"3-2\": \"MSISDN provided not an integer\",\n    \"3-1\": \"Fail\",\n    \"3-0\": \"010020\",\n    \"4-0\": \"010030\",\n    \"4-1\": \"Fail\",\n    \"4-2\": \"MSISDN Invalid\",\n    \"5-0\": \"010040\",\n    \"5-1\": \"Fail\",\n    \"5-2\": \"AccountID provided not an integer\",\n    \"6-0\": \"010050\",\n    \"6-1\": \"Fail\",\n    \"6-2\": \"RouteID provided not an integer\",\n    \"7-0\": \"010080\",\n    \"7-2\": \"TransID does not start with valid shard date (YYYYMM required)\",\n    \"7-1\": \"Fail\",\n    \"8-0\": \"010090\",\n    \"8-2\": \"Shard Date not set up yet (Future date)\",\n    \"8-1\": \"Fail\",\n    \"9-0\": \"010100\",\n    \"9-1\": \"Fail\",\n    \"9-2\": \"Invalid Retryfor\",\n    \"10-2\": \"Invalid priority\",\n    \"10-0\": \"010110\",\n    \"10-1\": \"Fail\",\n    \"11-0\": \"010150\",\n    \"11-1\": \"Fail\",\n    \"11-2\": \"No key\",\n    \"16-0\": \"010220\",\n    \"16-1\": \"Fail\",\n    \"16-2\": \"MSISDN Blacklisted\",\n    \"13-0\": \"010170\",\n    \"13-1\": \"Fail\",\n    \"13-2\": \"Sender not provided or over 12 characters\",\n    \"12-0\": \"010160\",\n    \"12-1\": \"Fail\",\n    \"12-2\": \"Invalid message\",\n    \"14-0\": \"010190\",\n    \"14-1\": \"Fail\",\n    \"14-2\": \"SendAt doesn't match format\"\n  },\n  \"cols\": 3,\n  \"rows\": 18\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Delivery Report Response Example\"\n}\n[/block]\nDelivery reports will be sent to the Alert URL provided when the request is submitted and includes the TransID that was submitted as well as the Route and Status code. \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://alerturl.com/transID=201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8&status=100000&route=T-mobile\",\n      \"language\": \"http\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Delivery Report Status Codes\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Code\",\n    \"h-1\": \"Type\",\n    \"h-2\": \"Description\",\n    \"0-0\": \"100000\",\n    \"0-1\": \"Success\",\n    \"1-0\": \"200310\",\n    \"1-1\": \"Fail\",\n    \"1-2\": \"Delivery failure\",\n    \"2-0\": \"200311\",\n    \"2-1\": \"Fail\",\n    \"2-2\": \"Delivery not permitted/possible\",\n    \"3-0\": \"200312\",\n    \"3-1\": \"Fail\",\n    \"3-2\": \"Unknown Destination\",\n    \"4-0\": \"200313\",\n    \"4-1\": \"Fail\",\n    \"4-2\": \"SMSC rejected destination\",\n    \"5-0\": \"200314\",\n    \"5-1\": \"Fail\",\n    \"5-2\": \"Customer category not allowed for third party\",\n    \"6-0\": \"200315\",\n    \"6-1\": \"Fail\",\n    \"6-2\": \"Destination Invalid\",\n    \"7-0\": \"200316\",\n    \"7-1\": \"Fail\",\n    \"7-2\": \"Prepay bar\",\n    \"8-0\": \"200317\",\n    \"8-1\": \"Fail\",\n    \"8-2\": \"Not a deliverable number\",\n    \"9-0\": \"200318\",\n    \"9-1\": \"Fail\",\n    \"9-2\": \"Content lock error\",\n    \"10-0\": \"200319\",\n    \"10-1\": \"Fail\",\n    \"10-2\": \"Not a subscriber\",\n    \"11-0\": \"200320\",\n    \"11-1\": \"Fail\",\n    \"11-2\": \"Reverse billed sms not allowed for subscriber\",\n    \"12-0\": \"200321\",\n    \"12-1\": \"Fail\",\n    \"12-2\": \"Subscriber account suspended\",\n    \"13-0\": \"200610\",\n    \"13-1\": \"Fail\",\n    \"13-2\": \"Destination is switched off\",\n    \"14-0\": \"200611\",\n    \"14-1\": \"Fail\",\n    \"14-2\": \"Destination is not responding\",\n    \"15-0\": \"200612\",\n    \"15-1\": \"Fail\",\n    \"15-2\": \"Error at  destination\",\n    \"16-0\": \"200613\",\n    \"16-1\": \"Fail\",\n    \"16-2\": \"Memory full at destination\",\n    \"17-0\": \"200614\",\n    \"17-1\": \"Fail\",\n    \"17-2\": \"Unspecified error\",\n    \"18-0\": \"200615\",\n    \"18-1\": \"Fail\",\n    \"18-2\": \"TPG system failure\",\n    \"19-0\": \"204010\",\n    \"19-1\": \"Fail\",\n    \"19-2\": \"Insufficient funds\"\n  },\n  \"cols\": 3,\n  \"rows\": 20\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"SMSSend Key\",\n  \"body\": \"Merchants must use the API key found in the RouteID Settings page on the Dashboard. The API Key will be used to determine which service the user should be linked to, where clickable links are being used in messages.\",\n  \"sidebar\": true\n}\n[/block]","category":"564b0ea41a8e610d006bfce0","createdAt":"2016-04-05T13:43:51.522Z","editedParams":true,"editedParams2":true,"excerpt":"","githubsync":"","hidden":false,"isReference":false,"link_external":false,"link_url":"","order":5,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"sms-send-api","sync_unique":"","title":"SMS Send API","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

SMS Send API


Merchants are able to use the SMS Send API to distribute marketing messages to consumers who have given consent. When the consumer clicks on a marketing link they are taken to the PaymentPage, from which they can continue on to make a purchase. [block:api-header] { "type": "basic", "title": "API Request parameters" } [/block] Requests to the SMS Send API should be submitted to the following URL as a GET request. [block:code] { "codes": [ { "code": "http://sms.impulsepay.com/smssend?", "language": "text" } ] } [/block] The following parameters should be included on all requests: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "MSISDN", "0-1": "The MSISDN the message is being sent to", "0-2": "\"447712345678\"", "1-0": "MSISDNtype", "1-1": "Specifies whether the number given in the MSISDN param is a MSISDN or MSISDNalias", "1-2": "MSISDN or ALIAS", "2-0": "Alert", "3-0": "Message", "3-1": "The message body for the text. This should be a maximum 160 characters.", "3-2": "hello world", "4-0": "Sender", "4-1": "The From field for the message being sent, which should be a maximum of 11 alphanumeric characters.", "4-2": "Test", "5-0": "CampaignID", "6-0": "Key", "6-1": "The merchant's SMS send API access key, which is provided by ImpulsePay", "6-2": "", "7-0": "TransID", "7-1": "A unique transaction ID generated for each individual message in the YYYYMM format", "8-0": "Note", "8-1": "The merchant can use the note for passing custom parameters through. This can be a maximum of 250 characters.", "9-0": "AffiliateID", "2-1": "The URL to send the delivery report to. This should be URLEncoded to prevent the request breaking.", "2-2": "http://www.domain.com/delrpt", "5-1": "A custom ID used by the merchant to identify different traffic sources running on a service. This can be a maximum of 15 0-9 or A-Z characters only.", "5-2": "ABC123", "7-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "9-1": "The merchant can use this to provide additional affiliate tracking information. The maximum Affiliate data that will be stored is limited to 250 characters.", "8-2": "Param1#Param2#Param3", "9-2": "123456789", "h-3": "Requirement", "0-3": "Mandatory", "1-3": "Mandatory", "2-3": "Mandatory", "3-3": "Mandatory", "4-3": "Mandatory", "5-3": "Mandatory", "6-3": "Mandatory", "7-3": "Mandatory", "8-3": "Optional", "9-3": "Optional", "10-0": "SendAt", "10-1": "The merchant can use this parameter to set a particular time to send the message. If left blank, the message will be sent straight-away.", "10-2": "yyyy-mm-dd hh:mm\nurl encoded (e.g 2016-04-05%2013%3A00)", "10-3": "Optional", "11-0": "udh", "11-1": "The merchant can use this value to string long text messages together so they appear concurrently to the user.", "11-2": "050003000201 \nSee details below.", "11-3": "Optional" }, "cols": 4, "rows": 12 } [/block] [block:api-header] { "type": "basic", "title": "Joining together messages over 160 characters in length" } [/block] Merchants are able to join messages that are longer than 160 characters by using the UDH parameter. By including this parameter in the correct format, long messages will appear joined on supported handsets. The UDH parameter is a long integer comprised of hexadecimals.The last 6 pairs of digits are the only digits which require configuration. For example, udh=050003**000201** and udh=050003**000202** would be used for a first and second message respectively, sent over two separate requests to the API. Of the last 6 pairs of digits, 00 remains the same for both values and serves as an ID for the set of messages. 02 refers to the total amount of messages to be joined, in this case 2. 01 refers to the current message, out of the total messages. [block:api-header] { "type": "basic", "title": "Adding clickable links to messages" } [/block] To prevent consumers having to verify their MSISDN when on wifi, a clickable link can be used. This substitutes the link with a secure code that contains the consumers MSISDN. When they proceed on to the PaymentPage, this can be used to identify the consumer and complete a purchase without verifying their MSISDN again. [block:code] { "codes": [ { "code": "http://bit.ly/##SMSLINK##", "language": "text" } ] } [/block] To enable this, merchants need to add a shortened URL link to their payment page followed by the placeholder ##SMSLink##. The secure code is the same length, so won't affect the overall message character count. [block:api-header] { "type": "basic", "title": "Example submission request" } [/block] [block:code] { "codes": [ { "code": "http://sms.impulsepay.com/smssend?MSISDN=447123456789&Alert=http%3A%2F%2Fdomain.com%2Fdelreport&TransID=201504-4567894143&message=HelloWorld&sender=Example&key=ABC123", "language": "html" } ] } [/block] [block:api-header] { "type": "basic", "title": "Submission Response Statuses" } [/block] Once a request has been submitted to SMS Send API, it will respond by writing a status code to indicate if the request has been successful or failed. [block:parameters] { "data": { "h-0": "Status Code", "h-1": "Type", "h-2": "Description", "1-0": "010070", "1-1": "Fail", "1-2": "Alert URL does not start http://", "15-0": "010200", "15-1": "Fail", "15-2": "MSISDN provided not valid", "2-0": "010010", "2-1": "Fail", "2-2": "TransID contains invalid characters", "0-0": "140000", "0-1": "Success", "17-0": "010999", "17-1": "Fail", "17-2": "Duplicate Billing Request", "3-2": "MSISDN provided not an integer", "3-1": "Fail", "3-0": "010020", "4-0": "010030", "4-1": "Fail", "4-2": "MSISDN Invalid", "5-0": "010040", "5-1": "Fail", "5-2": "AccountID provided not an integer", "6-0": "010050", "6-1": "Fail", "6-2": "RouteID provided not an integer", "7-0": "010080", "7-2": "TransID does not start with valid shard date (YYYYMM required)", "7-1": "Fail", "8-0": "010090", "8-2": "Shard Date not set up yet (Future date)", "8-1": "Fail", "9-0": "010100", "9-1": "Fail", "9-2": "Invalid Retryfor", "10-2": "Invalid priority", "10-0": "010110", "10-1": "Fail", "11-0": "010150", "11-1": "Fail", "11-2": "No key", "16-0": "010220", "16-1": "Fail", "16-2": "MSISDN Blacklisted", "13-0": "010170", "13-1": "Fail", "13-2": "Sender not provided or over 12 characters", "12-0": "010160", "12-1": "Fail", "12-2": "Invalid message", "14-0": "010190", "14-1": "Fail", "14-2": "SendAt doesn't match format" }, "cols": 3, "rows": 18 } [/block] [block:api-header] { "type": "basic", "title": "Delivery Report Response Example" } [/block] Delivery reports will be sent to the Alert URL provided when the request is submitted and includes the TransID that was submitted as well as the Route and Status code. [block:code] { "codes": [ { "code": "http://alerturl.com/transID=201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8&status=100000&route=T-mobile", "language": "http" } ] } [/block] [block:api-header] { "type": "basic", "title": "Delivery Report Status Codes" } [/block] [block:parameters] { "data": { "h-0": "Code", "h-1": "Type", "h-2": "Description", "0-0": "100000", "0-1": "Success", "1-0": "200310", "1-1": "Fail", "1-2": "Delivery failure", "2-0": "200311", "2-1": "Fail", "2-2": "Delivery not permitted/possible", "3-0": "200312", "3-1": "Fail", "3-2": "Unknown Destination", "4-0": "200313", "4-1": "Fail", "4-2": "SMSC rejected destination", "5-0": "200314", "5-1": "Fail", "5-2": "Customer category not allowed for third party", "6-0": "200315", "6-1": "Fail", "6-2": "Destination Invalid", "7-0": "200316", "7-1": "Fail", "7-2": "Prepay bar", "8-0": "200317", "8-1": "Fail", "8-2": "Not a deliverable number", "9-0": "200318", "9-1": "Fail", "9-2": "Content lock error", "10-0": "200319", "10-1": "Fail", "10-2": "Not a subscriber", "11-0": "200320", "11-1": "Fail", "11-2": "Reverse billed sms not allowed for subscriber", "12-0": "200321", "12-1": "Fail", "12-2": "Subscriber account suspended", "13-0": "200610", "13-1": "Fail", "13-2": "Destination is switched off", "14-0": "200611", "14-1": "Fail", "14-2": "Destination is not responding", "15-0": "200612", "15-1": "Fail", "15-2": "Error at destination", "16-0": "200613", "16-1": "Fail", "16-2": "Memory full at destination", "17-0": "200614", "17-1": "Fail", "17-2": "Unspecified error", "18-0": "200615", "18-1": "Fail", "18-2": "TPG system failure", "19-0": "204010", "19-1": "Fail", "19-2": "Insufficient funds" }, "cols": 3, "rows": 20 } [/block] [block:callout] { "type": "info", "title": "SMSSend Key", "body": "Merchants must use the API key found in the RouteID Settings page on the Dashboard. The API Key will be used to determine which service the user should be linked to, where clickable links are being used in messages.", "sidebar": true } [/block]
Merchants are able to use the SMS Send API to distribute marketing messages to consumers who have given consent. When the consumer clicks on a marketing link they are taken to the PaymentPage, from which they can continue on to make a purchase. [block:api-header] { "type": "basic", "title": "API Request parameters" } [/block] Requests to the SMS Send API should be submitted to the following URL as a GET request. [block:code] { "codes": [ { "code": "http://sms.impulsepay.com/smssend?", "language": "text" } ] } [/block] The following parameters should be included on all requests: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "MSISDN", "0-1": "The MSISDN the message is being sent to", "0-2": "\"447712345678\"", "1-0": "MSISDNtype", "1-1": "Specifies whether the number given in the MSISDN param is a MSISDN or MSISDNalias", "1-2": "MSISDN or ALIAS", "2-0": "Alert", "3-0": "Message", "3-1": "The message body for the text. This should be a maximum 160 characters.", "3-2": "hello world", "4-0": "Sender", "4-1": "The From field for the message being sent, which should be a maximum of 11 alphanumeric characters.", "4-2": "Test", "5-0": "CampaignID", "6-0": "Key", "6-1": "The merchant's SMS send API access key, which is provided by ImpulsePay", "6-2": "", "7-0": "TransID", "7-1": "A unique transaction ID generated for each individual message in the YYYYMM format", "8-0": "Note", "8-1": "The merchant can use the note for passing custom parameters through. This can be a maximum of 250 characters.", "9-0": "AffiliateID", "2-1": "The URL to send the delivery report to. This should be URLEncoded to prevent the request breaking.", "2-2": "http://www.domain.com/delrpt", "5-1": "A custom ID used by the merchant to identify different traffic sources running on a service. This can be a maximum of 15 0-9 or A-Z characters only.", "5-2": "ABC123", "7-2": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8", "9-1": "The merchant can use this to provide additional affiliate tracking information. The maximum Affiliate data that will be stored is limited to 250 characters.", "8-2": "Param1#Param2#Param3", "9-2": "123456789", "h-3": "Requirement", "0-3": "Mandatory", "1-3": "Mandatory", "2-3": "Mandatory", "3-3": "Mandatory", "4-3": "Mandatory", "5-3": "Mandatory", "6-3": "Mandatory", "7-3": "Mandatory", "8-3": "Optional", "9-3": "Optional", "10-0": "SendAt", "10-1": "The merchant can use this parameter to set a particular time to send the message. If left blank, the message will be sent straight-away.", "10-2": "yyyy-mm-dd hh:mm\nurl encoded (e.g 2016-04-05%2013%3A00)", "10-3": "Optional", "11-0": "udh", "11-1": "The merchant can use this value to string long text messages together so they appear concurrently to the user.", "11-2": "050003000201 \nSee details below.", "11-3": "Optional" }, "cols": 4, "rows": 12 } [/block] [block:api-header] { "type": "basic", "title": "Joining together messages over 160 characters in length" } [/block] Merchants are able to join messages that are longer than 160 characters by using the UDH parameter. By including this parameter in the correct format, long messages will appear joined on supported handsets. The UDH parameter is a long integer comprised of hexadecimals.The last 6 pairs of digits are the only digits which require configuration. For example, udh=050003**000201** and udh=050003**000202** would be used for a first and second message respectively, sent over two separate requests to the API. Of the last 6 pairs of digits, 00 remains the same for both values and serves as an ID for the set of messages. 02 refers to the total amount of messages to be joined, in this case 2. 01 refers to the current message, out of the total messages. [block:api-header] { "type": "basic", "title": "Adding clickable links to messages" } [/block] To prevent consumers having to verify their MSISDN when on wifi, a clickable link can be used. This substitutes the link with a secure code that contains the consumers MSISDN. When they proceed on to the PaymentPage, this can be used to identify the consumer and complete a purchase without verifying their MSISDN again. [block:code] { "codes": [ { "code": "http://bit.ly/##SMSLINK##", "language": "text" } ] } [/block] To enable this, merchants need to add a shortened URL link to their payment page followed by the placeholder ##SMSLink##. The secure code is the same length, so won't affect the overall message character count. [block:api-header] { "type": "basic", "title": "Example submission request" } [/block] [block:code] { "codes": [ { "code": "http://sms.impulsepay.com/smssend?MSISDN=447123456789&Alert=http%3A%2F%2Fdomain.com%2Fdelreport&TransID=201504-4567894143&message=HelloWorld&sender=Example&key=ABC123", "language": "html" } ] } [/block] [block:api-header] { "type": "basic", "title": "Submission Response Statuses" } [/block] Once a request has been submitted to SMS Send API, it will respond by writing a status code to indicate if the request has been successful or failed. [block:parameters] { "data": { "h-0": "Status Code", "h-1": "Type", "h-2": "Description", "1-0": "010070", "1-1": "Fail", "1-2": "Alert URL does not start http://", "15-0": "010200", "15-1": "Fail", "15-2": "MSISDN provided not valid", "2-0": "010010", "2-1": "Fail", "2-2": "TransID contains invalid characters", "0-0": "140000", "0-1": "Success", "17-0": "010999", "17-1": "Fail", "17-2": "Duplicate Billing Request", "3-2": "MSISDN provided not an integer", "3-1": "Fail", "3-0": "010020", "4-0": "010030", "4-1": "Fail", "4-2": "MSISDN Invalid", "5-0": "010040", "5-1": "Fail", "5-2": "AccountID provided not an integer", "6-0": "010050", "6-1": "Fail", "6-2": "RouteID provided not an integer", "7-0": "010080", "7-2": "TransID does not start with valid shard date (YYYYMM required)", "7-1": "Fail", "8-0": "010090", "8-2": "Shard Date not set up yet (Future date)", "8-1": "Fail", "9-0": "010100", "9-1": "Fail", "9-2": "Invalid Retryfor", "10-2": "Invalid priority", "10-0": "010110", "10-1": "Fail", "11-0": "010150", "11-1": "Fail", "11-2": "No key", "16-0": "010220", "16-1": "Fail", "16-2": "MSISDN Blacklisted", "13-0": "010170", "13-1": "Fail", "13-2": "Sender not provided or over 12 characters", "12-0": "010160", "12-1": "Fail", "12-2": "Invalid message", "14-0": "010190", "14-1": "Fail", "14-2": "SendAt doesn't match format" }, "cols": 3, "rows": 18 } [/block] [block:api-header] { "type": "basic", "title": "Delivery Report Response Example" } [/block] Delivery reports will be sent to the Alert URL provided when the request is submitted and includes the TransID that was submitted as well as the Route and Status code. [block:code] { "codes": [ { "code": "http://alerturl.com/transID=201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8&status=100000&route=T-mobile", "language": "http" } ] } [/block] [block:api-header] { "type": "basic", "title": "Delivery Report Status Codes" } [/block] [block:parameters] { "data": { "h-0": "Code", "h-1": "Type", "h-2": "Description", "0-0": "100000", "0-1": "Success", "1-0": "200310", "1-1": "Fail", "1-2": "Delivery failure", "2-0": "200311", "2-1": "Fail", "2-2": "Delivery not permitted/possible", "3-0": "200312", "3-1": "Fail", "3-2": "Unknown Destination", "4-0": "200313", "4-1": "Fail", "4-2": "SMSC rejected destination", "5-0": "200314", "5-1": "Fail", "5-2": "Customer category not allowed for third party", "6-0": "200315", "6-1": "Fail", "6-2": "Destination Invalid", "7-0": "200316", "7-1": "Fail", "7-2": "Prepay bar", "8-0": "200317", "8-1": "Fail", "8-2": "Not a deliverable number", "9-0": "200318", "9-1": "Fail", "9-2": "Content lock error", "10-0": "200319", "10-1": "Fail", "10-2": "Not a subscriber", "11-0": "200320", "11-1": "Fail", "11-2": "Reverse billed sms not allowed for subscriber", "12-0": "200321", "12-1": "Fail", "12-2": "Subscriber account suspended", "13-0": "200610", "13-1": "Fail", "13-2": "Destination is switched off", "14-0": "200611", "14-1": "Fail", "14-2": "Destination is not responding", "15-0": "200612", "15-1": "Fail", "15-2": "Error at destination", "16-0": "200613", "16-1": "Fail", "16-2": "Memory full at destination", "17-0": "200614", "17-1": "Fail", "17-2": "Unspecified error", "18-0": "200615", "18-1": "Fail", "18-2": "TPG system failure", "19-0": "204010", "19-1": "Fail", "19-2": "Insufficient funds" }, "cols": 3, "rows": 20 } [/block] [block:callout] { "type": "info", "title": "SMSSend Key", "body": "Merchants must use the API key found in the RouteID Settings page on the Dashboard. The API Key will be used to determine which service the user should be linked to, where clickable links are being used in messages.", "sidebar": true } [/block]
{"__v":4,"_id":"552f8a174329c20d00fa9cac","api":{"auth":"required","examples":{"codes":[{"name":"","code":"http://bill.impulsepay.com/LogAlias?MSISDN=447867805633&Key=0","language":"http"}]},"params":[{"_id":"552f8aa58f136c0d005031ea","required":false,"desc":"The MSISDN for which the merchant requires the appropriate MSISDNalias","default":"","type":"int","name":"MSISDN","in":"body"},{"_id":"552f8f96b09eaf0d008deb47","required":false,"desc":"The merchant's API access key","default":"","type":"mixed","name":"Key","in":"body"}],"results":{"codes":[{"name":"","code":"{}","language":"json","status":200}]},"settings":"","url":"http://bill.impulsepay.com/LogAlias?"},"body":"This API allows a merchant to get the MSISDNalias equivalent for a MSISDN. This API is useful where the merchant knows a consumer MSISDN in a customer care scenario and needs to match this to the MSISDNalias received in a billing notification. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"API parameters\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"MSISDN\",\n    \"0-1\": \"The consumer's MSISDN to check against MSISDNalias records\",\n    \"0-2\": \"\\\"44712345678\\\"\",\n    \"1-0\": \"Key\",\n    \"1-1\": \"The merchant's API access key\",\n    \"1-2\": \"\\\"abc123\\\"\"\n  },\n  \"cols\": 3,\n  \"rows\": 2\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Example request\"\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://bill.impulsepay.com/LogAlias?MSISDN=44712345678&Key=abc123\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Responses\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Response\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"INVALID\",\n    \"0-1\": \"No matching Alias was found for the MSISDN provided. Check it is properly formatted and begins 447.\",\n    \"1-0\": \"440712345678\",\n    \"1-1\": \"The Alias is returned if successfully matched against the MSISDN.\"\n  },\n  \"cols\": 2,\n  \"rows\": 2\n}\n[/block]","category":"564b0ea41a8e610d006bfce0","createdAt":"2015-04-16T10:08:23.747Z","editedParams":true,"editedParams2":true,"excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":7,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"alias-lookup-api","sync_unique":"","title":"Alias Lookup API","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Alias Lookup API


This API allows a merchant to get the MSISDNalias equivalent for a MSISDN. This API is useful where the merchant knows a consumer MSISDN in a customer care scenario and needs to match this to the MSISDNalias received in a billing notification. [block:api-header] { "type": "basic", "title": "API parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "MSISDN", "0-1": "The consumer's MSISDN to check against MSISDNalias records", "0-2": "\"44712345678\"", "1-0": "Key", "1-1": "The merchant's API access key", "1-2": "\"abc123\"" }, "cols": 3, "rows": 2 } [/block] [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/LogAlias?MSISDN=44712345678&Key=abc123", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] [block:parameters] { "data": { "h-0": "Response", "h-1": "Description", "0-0": "INVALID", "0-1": "No matching Alias was found for the MSISDN provided. Check it is properly formatted and begins 447.", "1-0": "440712345678", "1-1": "The Alias is returned if successfully matched against the MSISDN." }, "cols": 2, "rows": 2 } [/block]
This API allows a merchant to get the MSISDNalias equivalent for a MSISDN. This API is useful where the merchant knows a consumer MSISDN in a customer care scenario and needs to match this to the MSISDNalias received in a billing notification. [block:api-header] { "type": "basic", "title": "API parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "MSISDN", "0-1": "The consumer's MSISDN to check against MSISDNalias records", "0-2": "\"44712345678\"", "1-0": "Key", "1-1": "The merchant's API access key", "1-2": "\"abc123\"" }, "cols": 3, "rows": 2 } [/block] [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/LogAlias?MSISDN=44712345678&Key=abc123", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] [block:parameters] { "data": { "h-0": "Response", "h-1": "Description", "0-0": "INVALID", "0-1": "No matching Alias was found for the MSISDN provided. Check it is properly formatted and begins 447.", "1-0": "440712345678", "1-1": "The Alias is returned if successfully matched against the MSISDN." }, "cols": 2, "rows": 2 } [/block]
{"__v":9,"_id":"55310d11c68f493900aebb11","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"url":""},"body":"This API can be used to lookup the details for an active recurring payment.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://bill.impulsepay.com/CheckRecurringPayment?Key=&RPID=\",\n      \"language\": \"http\"\n    }\n  ]\n}\n[/block]\nThe following parameters are required: \n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter Name\",\n    \"h-1\": \"Value\",\n    \"0-0\": \"Key\",\n    \"1-0\": \"RPID\",\n    \"0-1\": \"API Key obtained from ImpulsePay\",\n    \"1-1\": \"Recurring Payment ID that was created at the time of the transaction\"\n  },\n  \"cols\": 2,\n  \"rows\": 2\n}\n[/block]\nIf data is found, the following parameters are returned in a JSON object:\n[block:parameters]\n{\n  \"data\": {\n    \"0-0\": \"MSISDN\",\n    \"2-0\": \"FriendlyName\",\n    \"3-0\": \"Tariff\",\n    \"4-0\": \"Operator\",\n    \"5-0\": \"NextCharge\",\n    \"6-0\": \"Frequency\",\n    \"7-0\": \"AccessPeriod\",\n    \"8-0\": \"Note\",\n    \"9-0\": \"AffiliateID\",\n    \"10-0\": \"LastBilled\",\n    \"11-0\": \"LastInteraction\",\n    \"12-0\": \"Anniversary\",\n    \"13-0\": \"TimesBilled\",\n    \"1-0\": \"MSISDNType\",\n    \"14-0\": \"CreatedAt\",\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-1\": \"The MSISDN or Alias for the consumer\",\n    \"1-1\": \"Flag to specify if this is a MSISDN or ALIAS being passed\",\n    \"0-2\": \"447123123123\",\n    \"1-2\": \"MSISDN | ALIAS\",\n    \"2-1\": \"FriendlyName that was passed in through the button on the Paywall engine\",\n    \"2-2\": \"Access24Hrs3\",\n    \"3-1\": \"The tariff (in pence) that the consumer was billed\",\n    \"3-2\": \"450 for £4.50\",\n    \"4-1\": \"The consumers mobile operator\",\n    \"4-2\": \"o2_uk, orange_uk, three_uk, tmobile_uk, virgin_uk, vodafone_uk\",\n    \"5-1\": \"The date for when the next charge is scheduled to be made, if not cancelled by the user\",\n    \"7-1\": \"Period of the recurring charges\",\n    \"6-1\": \"Frequency of the recurring charges\",\n    \"7-2\": \"WEEK \\nMONTH\",\n    \"6-2\": \"7\",\n    \"5-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"8-1\": \"Merchant specific parameters\",\n    \"9-1\": \"Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.\",\n    \"9-2\": \"A=1;B=2\",\n    \"8-2\": \"Param1#Param2#Param3\",\n    \"10-1\": \"Timestamp for when the transaction was last billed\",\n    \"10-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"11-1\": \"The last time the service was used (this is used to define the starting point of the 120 day inactivity rule).\",\n    \"12-1\": \"The date the last reminder text was sent for either £20 spend or 30 day reminder\",\n    \"13-1\": \"Number of times the MSISDN has been billed\",\n    \"14-1\": \"Timestamp for when the recurring payments started\",\n    \"11-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"12-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"14-2\": \"YYYY-MM-DD HH:MM:SS\",\n    \"13-2\": \"2\"\n  },\n  \"cols\": 3,\n  \"rows\": 15\n}\n[/block]\nIf not data is found, the following response will be sent\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"INVALID\",\n    \"0-1\": \"No records were found for the MSISDN or the MSISDN was incorrectly formatted.\"\n  },\n  \"cols\": 2,\n  \"rows\": 1\n}\n[/block]","category":"564b0ea41a8e610d006bfce0","createdAt":"2015-04-17T13:39:29.969Z","excerpt":"API to check the status of a recurring payment","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":8,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"check-recurring-payment-api","sync_unique":"","title":"RP Details API","type":"basic","updates":[],"user":"54eb3aaedf7add210007b26a","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

RP Details API

API to check the status of a recurring payment

This API can be used to lookup the details for an active recurring payment. [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/CheckRecurringPayment?Key=&RPID=", "language": "http" } ] } [/block] The following parameters are required: [block:parameters] { "data": { "h-0": "Parameter Name", "h-1": "Value", "0-0": "Key", "1-0": "RPID", "0-1": "API Key obtained from ImpulsePay", "1-1": "Recurring Payment ID that was created at the time of the transaction" }, "cols": 2, "rows": 2 } [/block] If data is found, the following parameters are returned in a JSON object: [block:parameters] { "data": { "0-0": "MSISDN", "2-0": "FriendlyName", "3-0": "Tariff", "4-0": "Operator", "5-0": "NextCharge", "6-0": "Frequency", "7-0": "AccessPeriod", "8-0": "Note", "9-0": "AffiliateID", "10-0": "LastBilled", "11-0": "LastInteraction", "12-0": "Anniversary", "13-0": "TimesBilled", "1-0": "MSISDNType", "14-0": "CreatedAt", "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-1": "The MSISDN or Alias for the consumer", "1-1": "Flag to specify if this is a MSISDN or ALIAS being passed", "0-2": "447123123123", "1-2": "MSISDN | ALIAS", "2-1": "FriendlyName that was passed in through the button on the Paywall engine", "2-2": "Access24Hrs3", "3-1": "The tariff (in pence) that the consumer was billed", "3-2": "450 for £4.50", "4-1": "The consumers mobile operator", "4-2": "o2_uk, orange_uk, three_uk, tmobile_uk, virgin_uk, vodafone_uk", "5-1": "The date for when the next charge is scheduled to be made, if not cancelled by the user", "7-1": "Period of the recurring charges", "6-1": "Frequency of the recurring charges", "7-2": "WEEK \nMONTH", "6-2": "7", "5-2": "YYYY-MM-DD HH:MM:SS", "8-1": "Merchant specific parameters", "9-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "9-2": "A=1;B=2", "8-2": "Param1#Param2#Param3", "10-1": "Timestamp for when the transaction was last billed", "10-2": "YYYY-MM-DD HH:MM:SS", "11-1": "The last time the service was used (this is used to define the starting point of the 120 day inactivity rule).", "12-1": "The date the last reminder text was sent for either £20 spend or 30 day reminder", "13-1": "Number of times the MSISDN has been billed", "14-1": "Timestamp for when the recurring payments started", "11-2": "YYYY-MM-DD HH:MM:SS", "12-2": "YYYY-MM-DD HH:MM:SS", "14-2": "YYYY-MM-DD HH:MM:SS", "13-2": "2" }, "cols": 3, "rows": 15 } [/block] If not data is found, the following response will be sent [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "INVALID", "0-1": "No records were found for the MSISDN or the MSISDN was incorrectly formatted." }, "cols": 2, "rows": 1 } [/block]
This API can be used to lookup the details for an active recurring payment. [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/CheckRecurringPayment?Key=&RPID=", "language": "http" } ] } [/block] The following parameters are required: [block:parameters] { "data": { "h-0": "Parameter Name", "h-1": "Value", "0-0": "Key", "1-0": "RPID", "0-1": "API Key obtained from ImpulsePay", "1-1": "Recurring Payment ID that was created at the time of the transaction" }, "cols": 2, "rows": 2 } [/block] If data is found, the following parameters are returned in a JSON object: [block:parameters] { "data": { "0-0": "MSISDN", "2-0": "FriendlyName", "3-0": "Tariff", "4-0": "Operator", "5-0": "NextCharge", "6-0": "Frequency", "7-0": "AccessPeriod", "8-0": "Note", "9-0": "AffiliateID", "10-0": "LastBilled", "11-0": "LastInteraction", "12-0": "Anniversary", "13-0": "TimesBilled", "1-0": "MSISDNType", "14-0": "CreatedAt", "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-1": "The MSISDN or Alias for the consumer", "1-1": "Flag to specify if this is a MSISDN or ALIAS being passed", "0-2": "447123123123", "1-2": "MSISDN | ALIAS", "2-1": "FriendlyName that was passed in through the button on the Paywall engine", "2-2": "Access24Hrs3", "3-1": "The tariff (in pence) that the consumer was billed", "3-2": "450 for £4.50", "4-1": "The consumers mobile operator", "4-2": "o2_uk, orange_uk, three_uk, tmobile_uk, virgin_uk, vodafone_uk", "5-1": "The date for when the next charge is scheduled to be made, if not cancelled by the user", "7-1": "Period of the recurring charges", "6-1": "Frequency of the recurring charges", "7-2": "WEEK \nMONTH", "6-2": "7", "5-2": "YYYY-MM-DD HH:MM:SS", "8-1": "Merchant specific parameters", "9-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "9-2": "A=1;B=2", "8-2": "Param1#Param2#Param3", "10-1": "Timestamp for when the transaction was last billed", "10-2": "YYYY-MM-DD HH:MM:SS", "11-1": "The last time the service was used (this is used to define the starting point of the 120 day inactivity rule).", "12-1": "The date the last reminder text was sent for either £20 spend or 30 day reminder", "13-1": "Number of times the MSISDN has been billed", "14-1": "Timestamp for when the recurring payments started", "11-2": "YYYY-MM-DD HH:MM:SS", "12-2": "YYYY-MM-DD HH:MM:SS", "14-2": "YYYY-MM-DD HH:MM:SS", "13-2": "2" }, "cols": 3, "rows": 15 } [/block] If not data is found, the following response will be sent [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "INVALID", "0-1": "No records were found for the MSISDN or the MSISDN was incorrectly formatted." }, "cols": 2, "rows": 1 } [/block]
{"__v":8,"_id":"553114f929603d2300011329","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"url":""},"body":"The Get recurring payments API can be used by merchants to query a MSISDN against the Recurring Payments database and obtain a list of recurring payment cycles that the MSISDN is currently opted into. The list is returned in a format containing unique identifiers for each recurring payment that has been set up.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"API parameters\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"Example\",\n    \"0-0\": \"MSISDN\",\n    \"0-1\": \"The number to check against the database for open recurring payment cycles.\",\n    \"0-2\": \"447712345678\",\n    \"2-0\": \"Key\",\n    \"2-1\": \"The merchants API access key\",\n    \"2-2\": \"ABC123\",\n    \"1-0\": \"MSISDNType\",\n    \"1-1\": \"Flag to specify if this is a MSISDN or ALIAS being passed\",\n    \"1-2\": \"MSISDN | ALIAS\"\n  },\n  \"cols\": 3,\n  \"rows\": 3\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Example request\"\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://bill.impulsepay.com/getrecurringpayment?MSISDN=&Key=\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Responses\"\n}\n[/block]\nThe response will be a comma delimited list of active RPIDs. If there are no active recurring payments then 'NONE' will be returned. \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8, 201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c9\",\n      \"language\": \"text\"\n    }\n  ]\n}\n[/block]","category":"564b0ea41a8e610d006bfce0","createdAt":"2015-04-17T14:13:13.528Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":9,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"get-recurring-payments-api","sync_unique":"","title":"Get All RPs API","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Get All RPs API


The Get recurring payments API can be used by merchants to query a MSISDN against the Recurring Payments database and obtain a list of recurring payment cycles that the MSISDN is currently opted into. The list is returned in a format containing unique identifiers for each recurring payment that has been set up. [block:api-header] { "type": "basic", "title": "API parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "MSISDN", "0-1": "The number to check against the database for open recurring payment cycles.", "0-2": "447712345678", "2-0": "Key", "2-1": "The merchants API access key", "2-2": "ABC123", "1-0": "MSISDNType", "1-1": "Flag to specify if this is a MSISDN or ALIAS being passed", "1-2": "MSISDN | ALIAS" }, "cols": 3, "rows": 3 } [/block] [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/getrecurringpayment?MSISDN=&Key=", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] The response will be a comma delimited list of active RPIDs. If there are no active recurring payments then 'NONE' will be returned. [block:code] { "codes": [ { "code": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8, 201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c9", "language": "text" } ] } [/block]
The Get recurring payments API can be used by merchants to query a MSISDN against the Recurring Payments database and obtain a list of recurring payment cycles that the MSISDN is currently opted into. The list is returned in a format containing unique identifiers for each recurring payment that has been set up. [block:api-header] { "type": "basic", "title": "API parameters" } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "Example", "0-0": "MSISDN", "0-1": "The number to check against the database for open recurring payment cycles.", "0-2": "447712345678", "2-0": "Key", "2-1": "The merchants API access key", "2-2": "ABC123", "1-0": "MSISDNType", "1-1": "Flag to specify if this is a MSISDN or ALIAS being passed", "1-2": "MSISDN | ALIAS" }, "cols": 3, "rows": 3 } [/block] [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/getrecurringpayment?MSISDN=&Key=", "language": "text" } ] } [/block] [block:api-header] { "type": "basic", "title": "Responses" } [/block] The response will be a comma delimited list of active RPIDs. If there are no active recurring payments then 'NONE' will be returned. [block:code] { "codes": [ { "code": "201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c8, 201502-ABCDE-839abe2c-1daf-44a7-85d0-e74ecb1e23c9", "language": "text" } ] } [/block]
{"project":"54eb3720df7add210007b257","version":"5524f5bbd919032b0057ac33","category":"564b0ea41a8e610d006bfce0","_id":"5776702104f7500e0095dafb","user":"54eb0de5f863c80d00705f29","updates":[],"createdAt":"2016-07-01T13:29:05.569Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":999,"body":"The Check RouteID Config API can be used to lookup all of the currently active templates set up for a RouteID. \n\nThe API will return a JSON object containing various Device Types (as detailed below) and the templates that are currently assigned for each. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Example Request\"\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://bill.impulsepay.com/checkRouteID-view?RouteID=&Key=\",\n      \"language\": \"http\"\n    }\n  ]\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"\",\n    \"0-0\": \"RouteID\",\n    \"0-1\": \"The 4 character URL RouteID value given at the top of the RouteID settings page\",\n    \"0-2\": \"LF0Y\",\n    \"1-0\": \"Key\",\n    \"1-1\": \"The merchant API access key provided on the Account Details dashboard page.\"\n  },\n  \"cols\": 2,\n  \"rows\": 2\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Response\"\n}\n[/block]\nThe response will be a JSON object with the following structure. \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"{\\n\\\"results\\\": [{\\n\\\"DeviceType\\\": \\\"desktop\\\",\\n\\\"RouteA\\\": {\\n\\\"TemplateID\\\": “AAAAAA”,\\n\\\"TemplateName\\\": “Template 1”\\n},\\n\\\"RouteB\\\": {\\n\\\"TemplateID\\\": “BBBBBB”,\\n\\\"TemplateName\\\": “Template 2”\\n},\\n\\\"RouteAll\\\": {\\n\\\"TemplateID\\\": \\\"\\\",\\n\\\"TemplateName\\\": \\\"\\\"\\n},\\n\\\"Success\\\": {\\n\\\"TemplateID\\\": “CCCCCC”,\\n\\\"TemplateName\\\": \\\"Template 3”\\n}\\n}, {\\n\\\"DeviceType\\\": \\\"ipad\\\",\\n\\\"RouteA\\\": {\\n\\\"TemplateID\\\": “DDDDDD”,\\n\\\"TemplateName\\\": \\\"Template 4”\\n},\\n\\\"RouteB\\\": {\\n\\\"TemplateID\\\": “EEEEEE”,\\n\\\"TemplateName\\\": \\\"Template 5”\\n},\\n\\\"RouteAll\\\": {\\n\\\"TemplateID\\\": \\\"\\\",\\n\\\"TemplateName\\\": \\\"\\\"\\n},\\n\\\"Success\\\": {\\n\\\"TemplateID\\\": “FFFFFF”,\\n\\\"TemplateName\\\": \\\"Template 6”\\n}\\n}, {…}, {…}, {…} ]\\n}\",\n      \"language\": \"json\"\n    }\n  ]\n}\n[/block]\nThe following Device Types should be expected: \n\ndesktop\nipad\niphone\niphone_O2_UK\niphone_Three_UK \niphone_EE_UK\niphone_Vodafone_UK \nandroid \nandroid_O2_UK \nandroid_Three_UK \nandroid_EE_UK \nandroid_Vodafone_UK \nmobile \nmobile_O2_UK\nmobile_Three_UK \nmobile_EE_UK \nmobile_Vodafone_UK","excerpt":"","slug":"check-routeid-config-api","type":"basic","title":"Check RouteID Config API","__v":0,"childrenPages":[]}

Check RouteID Config API


The Check RouteID Config API can be used to lookup all of the currently active templates set up for a RouteID. The API will return a JSON object containing various Device Types (as detailed below) and the templates that are currently assigned for each. [block:api-header] { "type": "basic", "title": "Example Request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/checkRouteID-view?RouteID=&Key=", "language": "http" } ] } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "", "0-0": "RouteID", "0-1": "The 4 character URL RouteID value given at the top of the RouteID settings page", "0-2": "LF0Y", "1-0": "Key", "1-1": "The merchant API access key provided on the Account Details dashboard page." }, "cols": 2, "rows": 2 } [/block] [block:api-header] { "type": "basic", "title": "Response" } [/block] The response will be a JSON object with the following structure. [block:code] { "codes": [ { "code": "{\n\"results\": [{\n\"DeviceType\": \"desktop\",\n\"RouteA\": {\n\"TemplateID\": “AAAAAA”,\n\"TemplateName\": “Template 1”\n},\n\"RouteB\": {\n\"TemplateID\": “BBBBBB”,\n\"TemplateName\": “Template 2”\n},\n\"RouteAll\": {\n\"TemplateID\": \"\",\n\"TemplateName\": \"\"\n},\n\"Success\": {\n\"TemplateID\": “CCCCCC”,\n\"TemplateName\": \"Template 3”\n}\n}, {\n\"DeviceType\": \"ipad\",\n\"RouteA\": {\n\"TemplateID\": “DDDDDD”,\n\"TemplateName\": \"Template 4”\n},\n\"RouteB\": {\n\"TemplateID\": “EEEEEE”,\n\"TemplateName\": \"Template 5”\n},\n\"RouteAll\": {\n\"TemplateID\": \"\",\n\"TemplateName\": \"\"\n},\n\"Success\": {\n\"TemplateID\": “FFFFFF”,\n\"TemplateName\": \"Template 6”\n}\n}, {…}, {…}, {…} ]\n}", "language": "json" } ] } [/block] The following Device Types should be expected: desktop ipad iphone iphone_O2_UK iphone_Three_UK iphone_EE_UK iphone_Vodafone_UK android android_O2_UK android_Three_UK android_EE_UK android_Vodafone_UK mobile mobile_O2_UK mobile_Three_UK mobile_EE_UK mobile_Vodafone_UK
The Check RouteID Config API can be used to lookup all of the currently active templates set up for a RouteID. The API will return a JSON object containing various Device Types (as detailed below) and the templates that are currently assigned for each. [block:api-header] { "type": "basic", "title": "Example Request" } [/block] [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/checkRouteID-view?RouteID=&Key=", "language": "http" } ] } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "h-2": "", "0-0": "RouteID", "0-1": "The 4 character URL RouteID value given at the top of the RouteID settings page", "0-2": "LF0Y", "1-0": "Key", "1-1": "The merchant API access key provided on the Account Details dashboard page." }, "cols": 2, "rows": 2 } [/block] [block:api-header] { "type": "basic", "title": "Response" } [/block] The response will be a JSON object with the following structure. [block:code] { "codes": [ { "code": "{\n\"results\": [{\n\"DeviceType\": \"desktop\",\n\"RouteA\": {\n\"TemplateID\": “AAAAAA”,\n\"TemplateName\": “Template 1”\n},\n\"RouteB\": {\n\"TemplateID\": “BBBBBB”,\n\"TemplateName\": “Template 2”\n},\n\"RouteAll\": {\n\"TemplateID\": \"\",\n\"TemplateName\": \"\"\n},\n\"Success\": {\n\"TemplateID\": “CCCCCC”,\n\"TemplateName\": \"Template 3”\n}\n}, {\n\"DeviceType\": \"ipad\",\n\"RouteA\": {\n\"TemplateID\": “DDDDDD”,\n\"TemplateName\": \"Template 4”\n},\n\"RouteB\": {\n\"TemplateID\": “EEEEEE”,\n\"TemplateName\": \"Template 5”\n},\n\"RouteAll\": {\n\"TemplateID\": \"\",\n\"TemplateName\": \"\"\n},\n\"Success\": {\n\"TemplateID\": “FFFFFF”,\n\"TemplateName\": \"Template 6”\n}\n}, {…}, {…}, {…} ]\n}", "language": "json" } ] } [/block] The following Device Types should be expected: desktop ipad iphone iphone_O2_UK iphone_Three_UK iphone_EE_UK iphone_Vodafone_UK android android_O2_UK android_Three_UK android_EE_UK android_Vodafone_UK mobile mobile_O2_UK mobile_Three_UK mobile_EE_UK mobile_Vodafone_UK
{"__v":5,"_id":"577670e5e5682f0e00d51011","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"The Update Route API can be used to assign templates to a device type, within a pre-existing RouteID. \n\nTo assign templates to a RouteID, the templates must already be approved. \n\nFor split testing, a templateID should be specified for both RouteA and RouteB parameters. If only a RouteA templateID is specified, then split testing will not be used.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Example request\"\n}\n[/block]\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"bill.impulsepay.com/checkRouteID-update?RouteID=&Key=&DeviceType=&RouteA=&RouteB=&Confirmation=\",\n      \"language\": \"http\"\n    }\n  ]\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameters\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"RouteID\",\n    \"0-1\": \"The 4 character URL RouteID given at the top of the RouteID settings page.\",\n    \"1-0\": \"Key\",\n    \"1-1\": \"The merchants API key given on the Account Details page on the Dashboard.\",\n    \"2-0\": \"DeviceType\",\n    \"2-1\": \"One of the 17 device types to which templates can be assigned. (See below)\",\n    \"3-0\": \"RouteA\",\n    \"3-1\": \"TemplateID\\n\\nRegardless of whether split testing is being used, RouteA should contain the primary TemplateID.\",\n    \"4-0\": \"RouteB\",\n    \"4-1\": \"TemplateID\\n\\nFor split testing to be activated, a TemplateID should be specified under RouteB.\",\n    \"5-0\": \"Confirmation\",\n    \"5-1\": \"TemplateID\\n\\nSets the confirmation page.\"\n  },\n  \"cols\": 2,\n  \"rows\": 6\n}\n[/block]\nIf the request has been successful, 'Updated' will be written to the page.","category":"564b0ea41a8e610d006bfce0","createdAt":"2016-07-01T13:32:21.756Z","excerpt":"","githubsync":"","hidden":false,"isReference":false,"link_external":false,"link_url":"","order":999,"project":"54eb3720df7add210007b257","slug":"update-routeid-api","sync_unique":"","title":"Update RouteID API","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Update RouteID API


The Update Route API can be used to assign templates to a device type, within a pre-existing RouteID. To assign templates to a RouteID, the templates must already be approved. For split testing, a templateID should be specified for both RouteA and RouteB parameters. If only a RouteA templateID is specified, then split testing will not be used. [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "bill.impulsepay.com/checkRouteID-update?RouteID=&Key=&DeviceType=&RouteA=&RouteB=&Confirmation=", "language": "http" } ] } [/block] [block:parameters] { "data": { "h-0": "Parameters", "h-1": "Description", "0-0": "RouteID", "0-1": "The 4 character URL RouteID given at the top of the RouteID settings page.", "1-0": "Key", "1-1": "The merchants API key given on the Account Details page on the Dashboard.", "2-0": "DeviceType", "2-1": "One of the 17 device types to which templates can be assigned. (See below)", "3-0": "RouteA", "3-1": "TemplateID\n\nRegardless of whether split testing is being used, RouteA should contain the primary TemplateID.", "4-0": "RouteB", "4-1": "TemplateID\n\nFor split testing to be activated, a TemplateID should be specified under RouteB.", "5-0": "Confirmation", "5-1": "TemplateID\n\nSets the confirmation page." }, "cols": 2, "rows": 6 } [/block] If the request has been successful, 'Updated' will be written to the page.
The Update Route API can be used to assign templates to a device type, within a pre-existing RouteID. To assign templates to a RouteID, the templates must already be approved. For split testing, a templateID should be specified for both RouteA and RouteB parameters. If only a RouteA templateID is specified, then split testing will not be used. [block:api-header] { "type": "basic", "title": "Example request" } [/block] [block:code] { "codes": [ { "code": "bill.impulsepay.com/checkRouteID-update?RouteID=&Key=&DeviceType=&RouteA=&RouteB=&Confirmation=", "language": "http" } ] } [/block] [block:parameters] { "data": { "h-0": "Parameters", "h-1": "Description", "0-0": "RouteID", "0-1": "The 4 character URL RouteID given at the top of the RouteID settings page.", "1-0": "Key", "1-1": "The merchants API key given on the Account Details page on the Dashboard.", "2-0": "DeviceType", "2-1": "One of the 17 device types to which templates can be assigned. (See below)", "3-0": "RouteA", "3-1": "TemplateID\n\nRegardless of whether split testing is being used, RouteA should contain the primary TemplateID.", "4-0": "RouteB", "4-1": "TemplateID\n\nFor split testing to be activated, a TemplateID should be specified under RouteB.", "5-0": "Confirmation", "5-1": "TemplateID\n\nSets the confirmation page." }, "cols": 2, "rows": 6 } [/block] If the request has been successful, 'Updated' will be written to the page.
{"__v":6,"_id":"5524f5bdd919032b0057ac4b","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"url":""},"body":"[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"ImpulsePay Dashboard\",\n  \"body\": \"Please contact ImpulsePay to receive login credentials to access these Dashboard features.\",\n  \"sidebar\": true\n}\n[/block]\nDetailed Reports for individual services are available through the ImpulsePay dashboard, providing merchants with a range of metrics and statistics.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Conversion Rates\"\n}\n[/block]\nThis table provides a breakdown by actual volume of traffic and gives a percentage of subsequent conversions against various traffic types. This report allows for tracking of events such as interactions, plus the addition of custom event tracking as per merchant’s requirements.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/JbWTYP1YQjCvd4DKaACV_Screen%20Shot%202015-04-15%20at%2011.34.30.png\",\n        \"Screen Shot 2015-04-15 at 11.34.30.png\",\n        \"948\",\n        \"235\",\n        \"#349ac4\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Consumer Response Times\"\n}\n[/block]\nThis table shows how many seconds have elapsed before the consumer presses the purchase button for the first time on the payment page. Slower response times may indicate barriers or difficulties in using the payment page.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/CrXgE7KRRQ2qMSJY3CSR_Screen%20Shot%202015-04-15%20at%2011.35.58.png\",\n        \"Screen Shot 2015-04-15 at 11.35.58.png\",\n        \"954\",\n        \"276\",\n        \"#617eb9\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Revenue Comparisons\"\n}\n[/block]\nThis table provides an overview of revenue per 1000 hits, comparing 3G and WiFi routes. This allows merchants to accurately gauge traffic performance against revenues and spot where increased traffic may or may not have increased revenues accordingly. This report can also track the revenue-per-hit from SMS marketing message links, if used. Revenue breakdowns for 3G traffic can also be further broken down to a per-network basis if this is configured. \n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/bWDfMrDISK6TfitPikMx_Screen%20Shot%202015-04-15%20at%2011.36.42.png\",\n        \"Screen Shot 2015-04-15 at 11.36.42.png\",\n        \"947\",\n        \"164\",\n        \"#5771a5\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Total Quantities\"\n}\n[/block]\nThis report allows merchants to view the total number of transactions against billing status codes received. Each status code is then expandable to allow a per-network view of the status codes received.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/oEzKvn0IRBWNFN9Qv86o_Screen%20Shot%202015-04-15%20at%2011.44.41.png\",\n        \"Screen Shot 2015-04-15 at 11.44.41.png\",\n        \"947\",\n        \"257\",\n        \"#477558\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Service Revenue\"\n}\n[/block]\nThis report provides an overview of actual revenue per-access-route, broken down by 3G mobile traffic, wifi traffic, traffic obtained via SMS marketing links and any recurring payments.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/dXVpk5JgTHiBsaZJycAT_Screen%20Shot%202015-04-15%20at%2011.46.39.png\",\n        \"Screen Shot 2015-04-15 at 11.46.39.png\",\n        \"945\",\n        \"198\",\n        \"#539c40\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nThis report provides detail on how many repeat purchases are made by consumers in the selected time period, with up to 6 repeat purchases captured.","category":"5524f5bcd919032b0057ac38","createdAt":"2015-02-23T15:10:01.453Z","excerpt":"How to get the most out of the ImpulsePay Dashboard reporting features","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":0,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"dashboard-reporting","sync_unique":"","title":"Dashboard Reporting","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Dashboard Reporting

How to get the most out of the ImpulsePay Dashboard reporting features

[block:callout] { "type": "info", "title": "ImpulsePay Dashboard", "body": "Please contact ImpulsePay to receive login credentials to access these Dashboard features.", "sidebar": true } [/block] Detailed Reports for individual services are available through the ImpulsePay dashboard, providing merchants with a range of metrics and statistics. [block:api-header] { "type": "basic", "title": "Conversion Rates" } [/block] This table provides a breakdown by actual volume of traffic and gives a percentage of subsequent conversions against various traffic types. This report allows for tracking of events such as interactions, plus the addition of custom event tracking as per merchant’s requirements. [block:image] { "images": [ { "image": [ "https://files.readme.io/JbWTYP1YQjCvd4DKaACV_Screen%20Shot%202015-04-15%20at%2011.34.30.png", "Screen Shot 2015-04-15 at 11.34.30.png", "948", "235", "#349ac4", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Consumer Response Times" } [/block] This table shows how many seconds have elapsed before the consumer presses the purchase button for the first time on the payment page. Slower response times may indicate barriers or difficulties in using the payment page. [block:image] { "images": [ { "image": [ "https://files.readme.io/CrXgE7KRRQ2qMSJY3CSR_Screen%20Shot%202015-04-15%20at%2011.35.58.png", "Screen Shot 2015-04-15 at 11.35.58.png", "954", "276", "#617eb9", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Revenue Comparisons" } [/block] This table provides an overview of revenue per 1000 hits, comparing 3G and WiFi routes. This allows merchants to accurately gauge traffic performance against revenues and spot where increased traffic may or may not have increased revenues accordingly. This report can also track the revenue-per-hit from SMS marketing message links, if used. Revenue breakdowns for 3G traffic can also be further broken down to a per-network basis if this is configured. [block:image] { "images": [ { "image": [ "https://files.readme.io/bWDfMrDISK6TfitPikMx_Screen%20Shot%202015-04-15%20at%2011.36.42.png", "Screen Shot 2015-04-15 at 11.36.42.png", "947", "164", "#5771a5", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Total Quantities" } [/block] This report allows merchants to view the total number of transactions against billing status codes received. Each status code is then expandable to allow a per-network view of the status codes received. [block:image] { "images": [ { "image": [ "https://files.readme.io/oEzKvn0IRBWNFN9Qv86o_Screen%20Shot%202015-04-15%20at%2011.44.41.png", "Screen Shot 2015-04-15 at 11.44.41.png", "947", "257", "#477558", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Service Revenue" } [/block] This report provides an overview of actual revenue per-access-route, broken down by 3G mobile traffic, wifi traffic, traffic obtained via SMS marketing links and any recurring payments. [block:image] { "images": [ { "image": [ "https://files.readme.io/dXVpk5JgTHiBsaZJycAT_Screen%20Shot%202015-04-15%20at%2011.46.39.png", "Screen Shot 2015-04-15 at 11.46.39.png", "945", "198", "#539c40", "" ] } ] } [/block] This report provides detail on how many repeat purchases are made by consumers in the selected time period, with up to 6 repeat purchases captured.
[block:callout] { "type": "info", "title": "ImpulsePay Dashboard", "body": "Please contact ImpulsePay to receive login credentials to access these Dashboard features.", "sidebar": true } [/block] Detailed Reports for individual services are available through the ImpulsePay dashboard, providing merchants with a range of metrics and statistics. [block:api-header] { "type": "basic", "title": "Conversion Rates" } [/block] This table provides a breakdown by actual volume of traffic and gives a percentage of subsequent conversions against various traffic types. This report allows for tracking of events such as interactions, plus the addition of custom event tracking as per merchant’s requirements. [block:image] { "images": [ { "image": [ "https://files.readme.io/JbWTYP1YQjCvd4DKaACV_Screen%20Shot%202015-04-15%20at%2011.34.30.png", "Screen Shot 2015-04-15 at 11.34.30.png", "948", "235", "#349ac4", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Consumer Response Times" } [/block] This table shows how many seconds have elapsed before the consumer presses the purchase button for the first time on the payment page. Slower response times may indicate barriers or difficulties in using the payment page. [block:image] { "images": [ { "image": [ "https://files.readme.io/CrXgE7KRRQ2qMSJY3CSR_Screen%20Shot%202015-04-15%20at%2011.35.58.png", "Screen Shot 2015-04-15 at 11.35.58.png", "954", "276", "#617eb9", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Revenue Comparisons" } [/block] This table provides an overview of revenue per 1000 hits, comparing 3G and WiFi routes. This allows merchants to accurately gauge traffic performance against revenues and spot where increased traffic may or may not have increased revenues accordingly. This report can also track the revenue-per-hit from SMS marketing message links, if used. Revenue breakdowns for 3G traffic can also be further broken down to a per-network basis if this is configured. [block:image] { "images": [ { "image": [ "https://files.readme.io/bWDfMrDISK6TfitPikMx_Screen%20Shot%202015-04-15%20at%2011.36.42.png", "Screen Shot 2015-04-15 at 11.36.42.png", "947", "164", "#5771a5", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Total Quantities" } [/block] This report allows merchants to view the total number of transactions against billing status codes received. Each status code is then expandable to allow a per-network view of the status codes received. [block:image] { "images": [ { "image": [ "https://files.readme.io/oEzKvn0IRBWNFN9Qv86o_Screen%20Shot%202015-04-15%20at%2011.44.41.png", "Screen Shot 2015-04-15 at 11.44.41.png", "947", "257", "#477558", "" ] } ] } [/block] [block:api-header] { "type": "basic", "title": "Service Revenue" } [/block] This report provides an overview of actual revenue per-access-route, broken down by 3G mobile traffic, wifi traffic, traffic obtained via SMS marketing links and any recurring payments. [block:image] { "images": [ { "image": [ "https://files.readme.io/dXVpk5JgTHiBsaZJycAT_Screen%20Shot%202015-04-15%20at%2011.46.39.png", "Screen Shot 2015-04-15 at 11.46.39.png", "945", "198", "#539c40", "" ] } ] } [/block] This report provides detail on how many repeat purchases are made by consumers in the selected time period, with up to 6 repeat purchases captured.
{"__v":3,"_id":"564b120ee5d9d61700d5806e","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"The template revenue page is an easy way to access revenue information on a per template basis. \n\nTo access template revenue reporting, on the main Dashboard page, click the Template Revenue button in the RouteID selection box near the top of the page. \n\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Daily Reporting\"\n}\n[/block]\n\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/C2dlJrewTWpszIf8Piwg_Screen%20Shot%202015-11-17%20at%2012.31.41.png\",\n        \"Screen Shot 2015-11-17 at 12.31.41.png\",\n        \"1940\",\n        \"1130\",\n        \"#34b3e1\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nThe initial reporting view shows all templates with revenue per daily period. Merchants can use the date selection to define a set period, or click on individual templates to see extended revenue graphs for the selected template including revenue per thousand and conversion rate. Revenues can also be filtered by CampaignID by using the drop-down box. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Hourly Reporting\"\n}\n[/block]\n\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/wQ9sUxbESaWhXnkFe08P_Screen%20Shot%202015-11-17%20at%2012.47.33.png\",\n        \"Screen Shot 2015-11-17 at 12.47.33.png\",\n        \"1896\",\n        \"940\",\n        \"#3ab5e3\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nHourly view shows revenues per hourly period and can be accessed by pressing the Hourly View button. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Template Revenue Graphs\"\n}\n[/block]\nBy clicking on a template, merchants can view an interactive revenue per thousand and conversation rate graph for the selected template.  \n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/8MYZ80moQqOFac2lyVXn_Screen%20Shot%202015-11-17%20at%2012.32.17.png\",\n        \"Screen Shot 2015-11-17 at 12.32.17.png\",\n        \"1954\",\n        \"1224\",\n        \"#73a5d4\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]","category":"5524f5bcd919032b0057ac38","createdAt":"2015-11-17T11:39:58.046Z","excerpt":"Information on Template Revenue Reporting","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":1,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"template-revenue","sync_unique":"","title":"Template Revenue","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Template Revenue

Information on Template Revenue Reporting

The template revenue page is an easy way to access revenue information on a per template basis. To access template revenue reporting, on the main Dashboard page, click the Template Revenue button in the RouteID selection box near the top of the page. [block:api-header] { "type": "basic", "title": "Daily Reporting" } [/block] [block:image] { "images": [ { "image": [ "https://files.readme.io/C2dlJrewTWpszIf8Piwg_Screen%20Shot%202015-11-17%20at%2012.31.41.png", "Screen Shot 2015-11-17 at 12.31.41.png", "1940", "1130", "#34b3e1", "" ] } ] } [/block] The initial reporting view shows all templates with revenue per daily period. Merchants can use the date selection to define a set period, or click on individual templates to see extended revenue graphs for the selected template including revenue per thousand and conversion rate. Revenues can also be filtered by CampaignID by using the drop-down box. [block:api-header] { "type": "basic", "title": "Hourly Reporting" } [/block] [block:image] { "images": [ { "image": [ "https://files.readme.io/wQ9sUxbESaWhXnkFe08P_Screen%20Shot%202015-11-17%20at%2012.47.33.png", "Screen Shot 2015-11-17 at 12.47.33.png", "1896", "940", "#3ab5e3", "" ] } ] } [/block] Hourly view shows revenues per hourly period and can be accessed by pressing the Hourly View button. [block:api-header] { "type": "basic", "title": "Template Revenue Graphs" } [/block] By clicking on a template, merchants can view an interactive revenue per thousand and conversation rate graph for the selected template. [block:image] { "images": [ { "image": [ "https://files.readme.io/8MYZ80moQqOFac2lyVXn_Screen%20Shot%202015-11-17%20at%2012.32.17.png", "Screen Shot 2015-11-17 at 12.32.17.png", "1954", "1224", "#73a5d4", "" ] } ] } [/block]
The template revenue page is an easy way to access revenue information on a per template basis. To access template revenue reporting, on the main Dashboard page, click the Template Revenue button in the RouteID selection box near the top of the page. [block:api-header] { "type": "basic", "title": "Daily Reporting" } [/block] [block:image] { "images": [ { "image": [ "https://files.readme.io/C2dlJrewTWpszIf8Piwg_Screen%20Shot%202015-11-17%20at%2012.31.41.png", "Screen Shot 2015-11-17 at 12.31.41.png", "1940", "1130", "#34b3e1", "" ] } ] } [/block] The initial reporting view shows all templates with revenue per daily period. Merchants can use the date selection to define a set period, or click on individual templates to see extended revenue graphs for the selected template including revenue per thousand and conversion rate. Revenues can also be filtered by CampaignID by using the drop-down box. [block:api-header] { "type": "basic", "title": "Hourly Reporting" } [/block] [block:image] { "images": [ { "image": [ "https://files.readme.io/wQ9sUxbESaWhXnkFe08P_Screen%20Shot%202015-11-17%20at%2012.47.33.png", "Screen Shot 2015-11-17 at 12.47.33.png", "1896", "940", "#3ab5e3", "" ] } ] } [/block] Hourly view shows revenues per hourly period and can be accessed by pressing the Hourly View button. [block:api-header] { "type": "basic", "title": "Template Revenue Graphs" } [/block] By clicking on a template, merchants can view an interactive revenue per thousand and conversation rate graph for the selected template. [block:image] { "images": [ { "image": [ "https://files.readme.io/8MYZ80moQqOFac2lyVXn_Screen%20Shot%202015-11-17%20at%2012.32.17.png", "Screen Shot 2015-11-17 at 12.32.17.png", "1954", "1224", "#73a5d4", "" ] } ] } [/block]
{"__v":13,"_id":"5524f5bdd919032b0057ac5a","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"In some cases, ImpulsePay will expose Network Operator status codes to allow merchants to narrow down the cause of an error within each individual network. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Submission Errors\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Status code\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"ImpulsePay related status\",\n    \"0-0\": \"010010\",\n    \"0-1\": \"TransID contains invalid characters (A-Z, 0-9 and - only)\",\n    \"0-2\": \"N/A\",\n    \"1-0\": \"010020\",\n    \"1-1\": \"MSISDN not an integer\",\n    \"1-2\": \"N/A\",\n    \"2-0\": \"010030\",\n    \"2-1\": \"Not a valid UK MSISDN\",\n    \"2-2\": \"N/A\",\n    \"3-0\": \"010040\",\n    \"3-1\": \"AccountID not an integer\",\n    \"3-2\": \"N/A\",\n    \"4-0\": \"010050\",\n    \"4-1\": \"RouteID not an integer\",\n    \"4-2\": \"N/A\",\n    \"5-0\": \"010060\",\n    \"5-1\": \"Tariff not an integer\",\n    \"5-2\": \"N/A\",\n    \"6-0\": \"010070\",\n    \"6-1\": \"Alert URL does not start with http(s)://\",\n    \"6-2\": \"N/A\",\n    \"7-0\": \"010080\",\n    \"7-1\": \"TransID does not start with a valid shard date (YYYYMM required)\",\n    \"7-2\": \"N/A\",\n    \"8-0\": \"010090\",\n    \"8-1\": \"ShardDate not set up yet (e.g future date)\",\n    \"8-2\": \"N/A\",\n    \"9-0\": \"010100\",\n    \"9-1\": \"RetryFor is not an integer or less than 0 or greater than 4320\",\n    \"10-0\": \"010110\",\n    \"10-1\": \"Priority not 1, 2 or 3\",\n    \"10-2\": \"N/A\",\n    \"11-0\": \"010120\",\n    \"11-1\": \"Currency not GBP or EUR\",\n    \"11-2\": \"N/A\",\n    \"12-0\": \"010130\",\n    \"12-1\": \"IsAlive not Y or N\",\n    \"12-2\": \"N/A\",\n    \"13-0\": \"010140\",\n    \"13-1\": \"IsKnown route invalid (not configured in MNOMappings)\",\n    \"13-2\": \"N/A\",\n    \"21-0\": \"010999\",\n    \"21-1\": \"Error adding request (may be duplicate)\",\n    \"21-2\": \"N/A\",\n    \"22-0\": \"010999\",\n    \"22-1\": \"Duplicate billing request\",\n    \"22-2\": \"N/A\",\n    \"23-0\": \"000000\",\n    \"23-1\": \"Initial request accepted and logged (used for internal tracking)\",\n    \"23-2\": \"N/A\",\n    \"24-0\": \"200000\",\n    \"24-1\": \"Forced failed billing attempt\",\n    \"24-2\": \"200\",\n    \"26-0\": \"010150\",\n    \"26-1\": \"Invalid key\",\n    \"26-2\": \"N/A\",\n    \"9-2\": \"N/A\",\n    \"14-0\": \"010150\",\n    \"14-1\": \"Key Missing\",\n    \"14-2\": \"N/A\",\n    \"15-0\": \"010160\",\n    \"15-1\": \"Message invalid\",\n    \"15-2\": \"N/A\",\n    \"16-0\": \"010170\",\n    \"16-1\": \"Sender invalid\",\n    \"16-2\": \"N/A\",\n    \"17-0\": \"010180\",\n    \"17-1\": \"Invalid campaign ID\",\n    \"17-2\": \"N/A\",\n    \"18-0\": \"010200\",\n    \"18-1\": \"Invalid Alias\",\n    \"18-2\": \"N/A\",\n    \"19-0\": \"010210\",\n    \"19-1\": \"Not opted in\",\n    \"19-2\": \"N/A\",\n    \"20-0\": \"010220\",\n    \"20-1\": \"Blacklisted\",\n    \"20-2\": \"N/A\",\n    \"25-0\": \"208000\",\n    \"25-1\": \"120 deactivation rule limit reached without consumer reactivation, recurring payment cancelled.\"\n  },\n  \"cols\": 3,\n  \"rows\": 27\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"HLR Errors\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Status code\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"ImpulsePay related status\",\n    \"0-0\": \"207000\",\n    \"0-1\": \"Connection to Tyntec error\",\n    \"0-2\": \"207\",\n    \"1-0\": \"207919\",\n    \"1-1\": \"Route found, no MNOMapping in place\",\n    \"1-2\": \"207\"\n  },\n  \"cols\": 3,\n  \"rows\": 2\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Vodafone billing route\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Operator status code\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"ImpulsePay related status\",\n    \"0-0\": \"100000\",\n    \"0-1\": \"Transaction completed successfully\",\n    \"0-2\": \"100\",\n    \"1-0\": \"200110\",\n    \"1-1\": \"MerchantName or ServiceID not configured for Account\",\n    \"1-2\": \"200\",\n    \"2-0\": \"200120\",\n    \"2-1\": \"opcoReason - Rejected other\",\n    \"2-2\": \"200\",\n    \"3-0\": \"200130\",\n    \"3-1\": \"opcoReason - User not found\",\n    \"3-2\": \"200\",\n    \"4-0\": \"200140\",\n    \"4-1\": \"opcoReason - Denied other\",\n    \"4-2\": \"200\",\n    \"5-0\": \"200150\",\n    \"5-1\": \"opcoReason - Content blocked\",\n    \"5-2\": \"200\",\n    \"6-0\": \"200160\",\n    \"6-1\": \"opcoReason - System error\",\n    \"6-2\": \"200\",\n    \"7-0\": \"200170\",\n    \"7-1\": \"opcoReason - Validation error\",\n    \"7-2\": \"200\",\n    \"8-0\": \"200180\",\n    \"8-1\": \"opcoReason - User barred\",\n    \"8-2\": \"200\",\n    \"9-0\": \"200190\",\n    \"9-1\": \"The transaction ID provided in the operation does not exist.\",\n    \"9-2\": \"200\",\n    \"10-0\": \"200200\",\n    \"10-1\": \"User performs an usage request and does not have a valid subscription.\",\n    \"10-2\": \"200\",\n    \"11-0\": \"200210\",\n    \"11-1\": \"The package does not have any active price points\",\n    \"11-2\": \"200\",\n    \"12-0\": \"200220\",\n    \"12-1\": \"The service ID used is not recognised\",\n    \"12-2\": \"200\",\n    \"13-0\": \"200100\",\n    \"13-1\": \"Unmapped transaction failure\",\n    \"13-2\": \"200\",\n    \"14-0\": \"200510\",\n    \"14-1\": \"Unable to connect to VF gateway\",\n    \"14-2\": \"200\",\n    \"16-0\": \"200520\",\n    \"16-1\": \"Atomic connection error\",\n    \"16-2\": \"200\",\n    \"17-0\": \"200530\",\n    \"17-1\": \"User have a valid subscription but does not have sufficient credits to use the service\",\n    \"17-2\": \"200\",\n    \"18-0\": \"200540\",\n    \"18-1\": \"The payment failed in the billing system, check opcoReason for reason\",\n    \"18-2\": \"200\",\n    \"19-0\": \"200550\",\n    \"19-1\": \"Unrecognised usage complete response\",\n    \"19-2\": \"200\",\n    \"20-0\": \"200560\",\n    \"20-1\": \"Unrecognised usage response\",\n    \"20-2\": \"200\",\n    \"21-0\": \"204010\",\n    \"22-0\": \"204020\",\n    \"23-0\": \"204030\",\n    \"24-0\": \"204040\",\n    \"25-0\": \"\",\n    \"21-1\": \"opcoReason - insufficient funds\",\n    \"21-2\": \"204\",\n    \"22-1\": \"The individual transaction amount partner trading limit has been breached\",\n    \"22-2\": \"204\",\n    \"23-1\": \"The cumulative transaction amount partner trading limit has been breached\",\n    \"23-2\": \"204\",\n    \"24-1\": \"A credit or spend limit has been exceeded\",\n    \"24-2\": \"204\",\n    \"15-0\": \"200511\",\n    \"15-1\": \"Connection timeout\",\n    \"15-2\": \"200\"\n  },\n  \"cols\": 3,\n  \"rows\": 26\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"EE billing route\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Operator status code\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"ImpulsePay status\",\n    \"0-0\": \"200410\",\n    \"0-1\": \"Retrieve Failed. Shown if failed to receive data from the server\",\n    \"0-2\": \"200\",\n    \"1-0\": \"200412\",\n    \"1-1\": \"Insert of updated failed. Shown if the service failed to insert of update the database table\",\n    \"1-2\": \"200\",\n    \"2-0\": \"200414\",\n    \"2-1\": \"Technical Exception. Technical fault thrown by the XTC client\",\n    \"2-2\": \"200\",\n    \"3-0\": \"200416\",\n    \"3-1\": \"Service Unavailable. Thrown if the customer brand is not orange UK.\",\n    \"3-2\": \"200\",\n    \"4-0\": \"200418\",\n    \"4-1\": \"Charge not found. If the the charge is not found for the given subscription ID and phase.\",\n    \"4-2\": \"200\",\n    \"5-0\": \"200420\",\n    \"5-1\": \"Invalid input. The provided input is not valid.\",\n    \"5-2\": \"200\",\n    \"6-0\": \"200422\",\n    \"6-1\": \"Exception in remote service. Thrown if business fault is thrown from a downstream system.\",\n    \"6-2\": \"200\",\n    \"7-0\": \"200424\",\n    \"7-1\": \"Vat code not found.\",\n    \"7-2\": \"200\",\n    \"8-0\": \"200426\",\n    \"8-1\": \"Subscription type not found for the given subscription ID.\",\n    \"8-2\": \"200\",\n    \"9-0\": \"200428\",\n    \"9-1\": \"XTC unknown. Business fault thrown by the XTC client.\",\n    \"9-2\": \"200\",\n    \"10-0\": \"200430\",\n    \"10-1\": \"XTC invalid data. Business fault thrown by the XTC client.\",\n    \"10-2\": \"200\",\n    \"11-0\": \"200432\",\n    \"11-1\": \"Charge customer available. Wrapped business fault for the technical exception code UNKNOWN thrown by the BEM client.\",\n    \"11-2\": \"200\",\n    \"12-0\": \"200434\",\n    \"12-1\": \"Charge band not found. When we are unable to retrieve charge band by subscription ID and the subscription phase.\",\n    \"12-2\": \"200\",\n    \"13-0\": \"200436\",\n    \"13-1\": \"Product charge not configured.\",\n    \"13-2\": \"200\",\n    \"14-0\": \"200438\",\n    \"14-1\": \"Product charge is already configured.\",\n    \"14-2\": \"200\",\n    \"15-0\": \"200440\",\n    \"15-1\": \"Vender not authorised.\",\n    \"15-2\": \"200\",\n    \"16-0\": \"200442\",\n    \"16-1\": \"Subscription details not found.\",\n    \"16-2\": \"200\",\n    \"17-0\": \"200444\",\n    \"17-1\": \"Referrer not found for the corresponding sender in the eiMessageContext.\",\n    \"17-2\": \"200\",\n    \"18-0\": \"200446\",\n    \"18-1\": \"Exception in charging system.\",\n    \"18-2\": \"200\",\n    \"19-0\": \"200448\",\n    \"19-1\": \"Invalid input.\",\n    \"19-2\": \"200\",\n    \"20-0\": \"200450\",\n    \"20-1\": \"Paym account not found. Exception thrown from getpaymaccount web service.\",\n    \"20-2\": \"200\",\n    \"21-0\": \"200452\",\n    \"21-1\": \"Get paym account unavailable.\",\n    \"21-2\": \"200\",\n    \"22-0\": \"200454\",\n    \"22-1\": \"Exception in remote service. Unknown exception thrown from getpaymaccount web service.\",\n    \"22-2\": \"200\",\n    \"23-0\": \"204030\",\n    \"23-1\": \"Customer unable to pay.\",\n    \"23-2\": \"200\"\n  },\n  \"cols\": 3,\n  \"rows\": 24\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Orange billing route\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Operator status code\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"ImpulsePay related status\",\n    \"0-0\": \"100000\",\n    \"1-0\": \"210100\",\n    \"2-0\": \"200120\",\n    \"0-1\": \"Transaction successfully completed\",\n    \"0-2\": \"100\",\n    \"1-1\": \"Price point not available\",\n    \"1-2\": \"200\",\n    \"2-1\": \"Invalid MSISDN\",\n    \"2-2\": \"200\",\n    \"3-0\": \"200130\",\n    \"3-1\": \"Invalid subscription\",\n    \"3-2\": \"200\",\n    \"4-0\": \"200140\",\n    \"4-1\": \"Invalid charge amount\",\n    \"4-2\": \"200\",\n    \"5-0\": \"200150\",\n    \"5-1\": \"Invalid username/password/IP\",\n    \"5-2\": \"200\",\n    \"6-0\": \"200160\",\n    \"6-1\": \"Invalid product\",\n    \"6-2\": \"200\",\n    \"7-0\": \"200100\",\n    \"7-1\": \"Unmapped transaction failure\",\n    \"7-2\": \"200\",\n    \"8-0\": \"204010\",\n    \"8-1\": \"Daily/monthly credit limit reached\",\n    \"8-2\": \"204\",\n    \"9-0\": \"204020\",\n    \"9-1\": \"Insufficient credit on handset\",\n    \"9-2\": \"204\"\n  },\n  \"cols\": 3,\n  \"rows\": 10\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"TMobile billing route\"\n}\n[/block]\nMessage sending stage\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Operator status code\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"ImpulsePay related status\",\n    \"0-0\": \"210100\",\n    \"0-1\": \"Price point not available\",\n    \"0-2\": \"200\",\n    \"1-0\": \"200120\",\n    \"1-1\": \"Invalid message body length (max length 160 chars)\",\n    \"1-2\": \"200\",\n    \"2-0\": \"200130\",\n    \"2-1\": \"Message body missing when not configured as silent billing\",\n    \"2-2\": \"200\",\n    \"3-0\": \"200140\",\n    \"3-1\": \"Validity period exceeds 4320 minutes (144 x 30 minute intervals)\",\n    \"3-2\": \"200\",\n    \"4-0\": \"200210\",\n    \"4-1\": \"Prepay database error\",\n    \"4-2\": \"200\",\n    \"5-0\": \"200211\",\n    \"5-1\": \"Subscriber account suspended\",\n    \"5-2\": \"200\",\n    \"6-0\": \"200212\",\n    \"6-1\": \"MT-Charged SMS not allowed for subscriber\",\n    \"6-2\": \"200\",\n    \"7-0\": \"200213\",\n    \"7-1\": \"Not a customer\",\n    \"7-2\": \"200\",\n    \"8-0\": \"200214\",\n    \"8-1\": \"Customer category not allowed for Third Party (billing transferred to Virgin route)\",\n    \"8-2\": \"200\",\n    \"9-0\": \"200215\",\n    \"9-1\": \"Destination barred by prepay system\",\n    \"9-2\": \"200\",\n    \"10-0\": \"200216\",\n    \"10-1\": \"Prepay system bar\",\n    \"10-2\": \"200\",\n    \"11-0\": \"200217\",\n    \"11-1\": \"Unknown third party\",\n    \"11-2\": \"200\",\n    \"12-0\": \"200218\",\n    \"12-1\": \"Invalid element content\",\n    \"12-2\": \"200\",\n    \"13-0\": \"200219\",\n    \"13-1\": \"Account disabled\",\n    \"13-2\": \"200\",\n    \"14-0\": \"200220\",\n    \"14-1\": \"Ext_reference value have been used in the last 5 minutes\",\n    \"14-2\": \"200\",\n    \"15-0\": \"200221\",\n    \"15-1\": \"Operation not allowed\",\n    \"15-2\": \"200\",\n    \"16-0\": \"200222\",\n    \"16-1\": \"Not a deliverable number\",\n    \"16-2\": \"200\",\n    \"17-0\": \"200223\",\n    \"17-1\": \"Invalid service ID\",\n    \"17-2\": \"200\",\n    \"18-0\": \"200224\",\n    \"18-1\": \"Bad XML document\",\n    \"18-2\": \"200\",\n    \"19-0\": \"200225\",\n    \"19-1\": \"Content lock error\",\n    \"19-2\": \"200\",\n    \"20-0\": \"200226\",\n    \"20-1\": \"Feature query disabled\",\n    \"20-2\": \"200\",\n    \"21-0\": \"200227\",\n    \"21-1\": \"Immediate not allowed\",\n    \"21-2\": \"200\",\n    \"22-0\": \"200228\",\n    \"22-1\": \"Silent message not allowed\",\n    \"22-2\": \"200\",\n    \"23-0\": \"200229\",\n    \"23-1\": \"Replace message not allowed\",\n    \"23-2\": \"200\",\n    \"24-0\": \"200200\",\n    \"24-1\": \"Unmapped transaction failure\",\n    \"24-2\": \"200\",\n    \"25-0\": \"200510\",\n    \"25-1\": \"System failure\",\n    \"25-2\": \"200\",\n    \"26-0\": \"200511\",\n    \"26-1\": \"Queue size is too long\",\n    \"26-2\": \"200\",\n    \"27-0\": \"200512\",\n    \"27-1\": \"Allowed throughput limit reached. Retry later.\",\n    \"27-2\": \"200\",\n    \"28-0\": \"200513\",\n    \"28-1\": \"Customer database error\",\n    \"28-2\": \"200\",\n    \"29-0\": \"200514\",\n    \"29-1\": \"Backend timeout while processing the request\",\n    \"29-2\": \"200\",\n    \"30-0\": \"204010\",\n    \"30-1\": \"No funds\",\n    \"30-2\": \"204\"\n  },\n  \"cols\": 3,\n  \"rows\": 31\n}\n[/block]\nDelivery report stage\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Operator status code\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"ImpulsePay related stat\",\n    \"0-0\": \"100000\",\n    \"0-1\": \"Acknowledged delivery confirmed\",\n    \"0-2\": \"100\",\n    \"1-0\": \"200310\",\n    \"1-1\": \"Delivery failure\",\n    \"1-2\": \"200\",\n    \"2-0\": \"200311\",\n    \"2-1\": \"Delivery not permitted/possible\",\n    \"2-2\": \"200\",\n    \"3-0\": \"200312\",\n    \"3-1\": \"Unknown destination\",\n    \"3-2\": \"200\",\n    \"4-0\": \"200313\",\n    \"4-1\": \"SMSC rejected destination\",\n    \"4-2\": \"200\",\n    \"5-0\": \"200314\",\n    \"5-1\": \"Customer category not allowed for third party\",\n    \"5-2\": \"200\",\n    \"6-0\": \"200315\",\n    \"6-1\": \"Destination invalid\",\n    \"6-2\": \"200\",\n    \"7-0\": \"200316\",\n    \"7-1\": \"Prepay bar\",\n    \"7-2\": \"200\",\n    \"8-0\": \"200317\",\n    \"8-1\": \"Not a deliverable number\",\n    \"8-2\": \"200\",\n    \"9-0\": \"200318\",\n    \"9-1\": \"Content lock error\",\n    \"9-2\": \"200\",\n    \"10-0\": \"200319\",\n    \"10-1\": \"Not a subscriber\",\n    \"10-2\": \"200\",\n    \"11-0\": \"200320\",\n    \"11-1\": \"Reverse billed sms not allowed for subscriber\",\n    \"11-2\": \"200\",\n    \"12-0\": \"200321\",\n    \"12-1\": \"Subscriber account suspended\",\n    \"12-2\": \"200\",\n    \"13-0\": \"200300\",\n    \"13-1\": \"Unmapped transaction failure\",\n    \"13-2\": \"200\",\n    \"14-0\": \"200610\",\n    \"14-1\": \"Destination is detached (switched off)\",\n    \"14-2\": \"200\",\n    \"15-0\": \"200611\",\n    \"15-1\": \"Destination is not responding\",\n    \"15-2\": \"200\",\n    \"16-0\": \"200612\",\n    \"16-1\": \"Error at destination\",\n    \"16-2\": \"200\",\n    \"17-0\": \"200613\",\n    \"17-1\": \"Memory full at destination\",\n    \"17-2\": \"200\",\n    \"18-0\": \"200614\",\n    \"18-1\": \"Unspecified error\",\n    \"18-2\": \"200\",\n    \"19-0\": \"200615\",\n    \"19-1\": \"TPG system failure\",\n    \"19-2\": \"200\",\n    \"20-0\": \"204010\",\n    \"20-1\": \"Insufficient funds\",\n    \"20-2\": \"204\"\n  },\n  \"cols\": 3,\n  \"rows\": 21\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Three billing route\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Operator status code\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"ImpulsePay related status\",\n    \"0-0\": \"100000\",\n    \"0-1\": \"Transaction completed succesfully\",\n    \"0-2\": \"100\",\n    \"1-0\": \"200110\",\n    \"1-1\": \"Required billing text descriptor missing\",\n    \"1-2\": \"200\",\n    \"2-0\": \"200120\",\n    \"2-1\": \"Invalid input value\",\n    \"2-2\": \"200\",\n    \"3-0\": \"200130\",\n    \"3-1\": \"Invalid charging information\",\n    \"3-2\": \"200\",\n    \"4-0\": \"200140\",\n    \"4-1\": \"Charge failed\",\n    \"4-2\": \"200\",\n    \"5-0\": \"200150\",\n    \"5-1\": \"Policy error (Thrown in case some policy rule disallows the request)\",\n    \"5-2\": \"200\",\n    \"6-0\": \"200160\",\n    \"6-1\": \"Duplicate charge request\",\n    \"6-2\": \"200\",\n    \"7-0\": \"200170\",\n    \"7-1\": \"Adult verification failed\",\n    \"7-2\": \"200\",\n    \"8-0\": \"200180\",\n    \"8-1\": \"Unable to locate the specified subscriber\",\n    \"8-2\": \"200\",\n    \"9-0\": \"200190\",\n    \"9-1\": \"Subscriber restriction clause has failed\",\n    \"9-2\": \"200\",\n    \"10-0\": \"200200\",\n    \"10-1\": \"Request denied, no service contract found\",\n    \"10-2\": \"200\",\n    \"11-0\": \"200210\",\n    \"11-1\": \"The 3API session indentifier is not valid\",\n    \"11-2\": \"200\",\n    \"12-0\": \"200100\",\n    \"12-1\": \"Unmapped transaction failure\",\n    \"12-2\": \"200\",\n    \"13-0\": \"200220\",\n    \"13-1\": \"Outside payout range (10 - 3000 pence)\",\n    \"13-2\": \"200\",\n    \"14-0\": \"200510\",\n    \"14-1\": \"Service error (Thrown in case when there is an internal error)\",\n    \"14-2\": \"200\",\n    \"15-0\": \"204010\",\n    \"15-1\": \"Subscriber has insufficient funds\",\n    \"15-2\": \"204\"\n  },\n  \"cols\": 3,\n  \"rows\": 16\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Virgin billing route\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Operator status code\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"ImpulsePay related status\",\n    \"0-0\": \"100000\",\n    \"0-1\": \"Billing Successful\",\n    \"0-2\": \"100\",\n    \"1-0\": \"200000\",\n    \"1-1\": \"Billing Unsuccessful\",\n    \"1-2\": \"200\",\n    \"2-0\": \"210100\",\n    \"2-1\": \"Tariff Unavailable\",\n    \"2-2\": \"210100\"\n  },\n  \"cols\": 3,\n  \"rows\": 3\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"O2 billing route\"\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Operator status code\",\n    \"h-1\": \"Description\",\n    \"h-2\": \"ImpulsePay related status\",\n    \"0-0\": \"100000\",\n    \"0-1\": \"Transaction completed successfully\",\n    \"0-2\": \"100\",\n    \"2-0\": \"200110\",\n    \"2-1\": \"MerchantID value missing\",\n    \"2-2\": \"200\",\n    \"3-0\": \"200120\",\n    \"3-1\": \"The service has been set 'out of service' by the operations team\",\n    \"3-2\": \"200\",\n    \"4-0\": \"200130\",\n    \"4-1\": \"The request is malformed or the header does not contain the required fields.\",\n    \"4-2\": \"200\",\n    \"5-0\": \"200140\",\n    \"5-1\": \"The SOA transaction is not unique\",\n    \"5-2\": \"200\",\n    \"6-0\": \"200150\",\n    \"6-1\": \"The request is malformed or the header does not contain the required fields.\",\n    \"6-2\": \"200\",\n    \"7-0\": \"200160\",\n    \"7-1\": \"The currency code has been provided in the request\",\n    \"7-2\": \"200\",\n    \"8-0\": \"200170\",\n    \"8-1\": \"Subscription identifier is missing or item prices are zero\",\n    \"8-2\": \"200\",\n    \"9-0\": \"200180\",\n    \"9-1\": \"The external ID provided in the request is a duplicate\",\n    \"9-2\": \"200\",\n    \"10-0\": \"200190\",\n    \"10-1\": \"The account provided is invalid (MVNO/O2 Business, billing routed to PSMS)\",\n    \"10-2\": \"200\",\n    \"11-0\": \"200200\",\n    \"11-1\": \"The account provided is not eligible for content events due to a bar\",\n    \"11-2\": \"200\",\n    \"12-0\": \"200210\",\n    \"12-1\": \"The account provided is not allowed to receive the content type specified\",\n    \"12-2\": \"200\",\n    \"13-0\": \"200220\",\n    \"13-1\": \"The value of the transaction exceeds the maximum value allowed by the service\",\n    \"13-2\": \"200\",\n    \"14-0\": \"200230\",\n    \"14-1\": \"A refund using the same externalID has already been received\",\n    \"14-2\": \"200\",\n    \"17-0\": \"\",\n    \"17-1\": \"Unmapped transaction failure\",\n    \"17-2\": \"200\",\n    \"18-0\": \"200510\",\n    \"18-1\": \"A system error has occurred, that cannot be represented by alternative error codes\",\n    \"18-2\": \"200\",\n    \"19-0\": \"200520\",\n    \"19-1\": \"The system is busy, for example throttling limits have been reached\",\n    \"19-2\": \"200\",\n    \"20-0\": \"204010\",\n    \"20-1\": \"Insufficient funds to apply the debit operation\",\n    \"20-2\": \"204\",\n    \"15-0\": \"200240\",\n    \"16-0\": \"200250\",\n    \"15-1\": \"O2 Billing limit reached\",\n    \"15-2\": \"200\",\n    \"16-1\": \"Not attempted on PSMS\",\n    \"16-2\": \"200\",\n    \"1-0\": \"200100\",\n    \"1-1\": \"Undefined/Unavailable tariff\",\n    \"1-2\": \"210\"\n  },\n  \"cols\": 3,\n  \"rows\": 21\n}\n[/block]","category":"5524f5bcd919032b0057ac39","createdAt":"2015-03-05T15:12:02.809Z","excerpt":"","githubsync":"","hidden":false,"isReference":false,"link_external":false,"link_url":"","order":0,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"operator-status-codes","sync_unique":"","title":"Operator Status Codes","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Operator Status Codes


In some cases, ImpulsePay will expose Network Operator status codes to allow merchants to narrow down the cause of an error within each individual network. [block:api-header] { "type": "basic", "title": "Submission Errors" } [/block] [block:parameters] { "data": { "h-0": "Status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "010010", "0-1": "TransID contains invalid characters (A-Z, 0-9 and - only)", "0-2": "N/A", "1-0": "010020", "1-1": "MSISDN not an integer", "1-2": "N/A", "2-0": "010030", "2-1": "Not a valid UK MSISDN", "2-2": "N/A", "3-0": "010040", "3-1": "AccountID not an integer", "3-2": "N/A", "4-0": "010050", "4-1": "RouteID not an integer", "4-2": "N/A", "5-0": "010060", "5-1": "Tariff not an integer", "5-2": "N/A", "6-0": "010070", "6-1": "Alert URL does not start with http(s)://", "6-2": "N/A", "7-0": "010080", "7-1": "TransID does not start with a valid shard date (YYYYMM required)", "7-2": "N/A", "8-0": "010090", "8-1": "ShardDate not set up yet (e.g future date)", "8-2": "N/A", "9-0": "010100", "9-1": "RetryFor is not an integer or less than 0 or greater than 4320", "10-0": "010110", "10-1": "Priority not 1, 2 or 3", "10-2": "N/A", "11-0": "010120", "11-1": "Currency not GBP or EUR", "11-2": "N/A", "12-0": "010130", "12-1": "IsAlive not Y or N", "12-2": "N/A", "13-0": "010140", "13-1": "IsKnown route invalid (not configured in MNOMappings)", "13-2": "N/A", "21-0": "010999", "21-1": "Error adding request (may be duplicate)", "21-2": "N/A", "22-0": "010999", "22-1": "Duplicate billing request", "22-2": "N/A", "23-0": "000000", "23-1": "Initial request accepted and logged (used for internal tracking)", "23-2": "N/A", "24-0": "200000", "24-1": "Forced failed billing attempt", "24-2": "200", "26-0": "010150", "26-1": "Invalid key", "26-2": "N/A", "9-2": "N/A", "14-0": "010150", "14-1": "Key Missing", "14-2": "N/A", "15-0": "010160", "15-1": "Message invalid", "15-2": "N/A", "16-0": "010170", "16-1": "Sender invalid", "16-2": "N/A", "17-0": "010180", "17-1": "Invalid campaign ID", "17-2": "N/A", "18-0": "010200", "18-1": "Invalid Alias", "18-2": "N/A", "19-0": "010210", "19-1": "Not opted in", "19-2": "N/A", "20-0": "010220", "20-1": "Blacklisted", "20-2": "N/A", "25-0": "208000", "25-1": "120 deactivation rule limit reached without consumer reactivation, recurring payment cancelled." }, "cols": 3, "rows": 27 } [/block] [block:api-header] { "type": "basic", "title": "HLR Errors" } [/block] [block:parameters] { "data": { "h-0": "Status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "207000", "0-1": "Connection to Tyntec error", "0-2": "207", "1-0": "207919", "1-1": "Route found, no MNOMapping in place", "1-2": "207" }, "cols": 3, "rows": 2 } [/block] [block:api-header] { "type": "basic", "title": "Vodafone billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "100000", "0-1": "Transaction completed successfully", "0-2": "100", "1-0": "200110", "1-1": "MerchantName or ServiceID not configured for Account", "1-2": "200", "2-0": "200120", "2-1": "opcoReason - Rejected other", "2-2": "200", "3-0": "200130", "3-1": "opcoReason - User not found", "3-2": "200", "4-0": "200140", "4-1": "opcoReason - Denied other", "4-2": "200", "5-0": "200150", "5-1": "opcoReason - Content blocked", "5-2": "200", "6-0": "200160", "6-1": "opcoReason - System error", "6-2": "200", "7-0": "200170", "7-1": "opcoReason - Validation error", "7-2": "200", "8-0": "200180", "8-1": "opcoReason - User barred", "8-2": "200", "9-0": "200190", "9-1": "The transaction ID provided in the operation does not exist.", "9-2": "200", "10-0": "200200", "10-1": "User performs an usage request and does not have a valid subscription.", "10-2": "200", "11-0": "200210", "11-1": "The package does not have any active price points", "11-2": "200", "12-0": "200220", "12-1": "The service ID used is not recognised", "12-2": "200", "13-0": "200100", "13-1": "Unmapped transaction failure", "13-2": "200", "14-0": "200510", "14-1": "Unable to connect to VF gateway", "14-2": "200", "16-0": "200520", "16-1": "Atomic connection error", "16-2": "200", "17-0": "200530", "17-1": "User have a valid subscription but does not have sufficient credits to use the service", "17-2": "200", "18-0": "200540", "18-1": "The payment failed in the billing system, check opcoReason for reason", "18-2": "200", "19-0": "200550", "19-1": "Unrecognised usage complete response", "19-2": "200", "20-0": "200560", "20-1": "Unrecognised usage response", "20-2": "200", "21-0": "204010", "22-0": "204020", "23-0": "204030", "24-0": "204040", "25-0": "", "21-1": "opcoReason - insufficient funds", "21-2": "204", "22-1": "The individual transaction amount partner trading limit has been breached", "22-2": "204", "23-1": "The cumulative transaction amount partner trading limit has been breached", "23-2": "204", "24-1": "A credit or spend limit has been exceeded", "24-2": "204", "15-0": "200511", "15-1": "Connection timeout", "15-2": "200" }, "cols": 3, "rows": 26 } [/block] [block:api-header] { "type": "basic", "title": "EE billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay status", "0-0": "200410", "0-1": "Retrieve Failed. Shown if failed to receive data from the server", "0-2": "200", "1-0": "200412", "1-1": "Insert of updated failed. Shown if the service failed to insert of update the database table", "1-2": "200", "2-0": "200414", "2-1": "Technical Exception. Technical fault thrown by the XTC client", "2-2": "200", "3-0": "200416", "3-1": "Service Unavailable. Thrown if the customer brand is not orange UK.", "3-2": "200", "4-0": "200418", "4-1": "Charge not found. If the the charge is not found for the given subscription ID and phase.", "4-2": "200", "5-0": "200420", "5-1": "Invalid input. The provided input is not valid.", "5-2": "200", "6-0": "200422", "6-1": "Exception in remote service. Thrown if business fault is thrown from a downstream system.", "6-2": "200", "7-0": "200424", "7-1": "Vat code not found.", "7-2": "200", "8-0": "200426", "8-1": "Subscription type not found for the given subscription ID.", "8-2": "200", "9-0": "200428", "9-1": "XTC unknown. Business fault thrown by the XTC client.", "9-2": "200", "10-0": "200430", "10-1": "XTC invalid data. Business fault thrown by the XTC client.", "10-2": "200", "11-0": "200432", "11-1": "Charge customer available. Wrapped business fault for the technical exception code UNKNOWN thrown by the BEM client.", "11-2": "200", "12-0": "200434", "12-1": "Charge band not found. When we are unable to retrieve charge band by subscription ID and the subscription phase.", "12-2": "200", "13-0": "200436", "13-1": "Product charge not configured.", "13-2": "200", "14-0": "200438", "14-1": "Product charge is already configured.", "14-2": "200", "15-0": "200440", "15-1": "Vender not authorised.", "15-2": "200", "16-0": "200442", "16-1": "Subscription details not found.", "16-2": "200", "17-0": "200444", "17-1": "Referrer not found for the corresponding sender in the eiMessageContext.", "17-2": "200", "18-0": "200446", "18-1": "Exception in charging system.", "18-2": "200", "19-0": "200448", "19-1": "Invalid input.", "19-2": "200", "20-0": "200450", "20-1": "Paym account not found. Exception thrown from getpaymaccount web service.", "20-2": "200", "21-0": "200452", "21-1": "Get paym account unavailable.", "21-2": "200", "22-0": "200454", "22-1": "Exception in remote service. Unknown exception thrown from getpaymaccount web service.", "22-2": "200", "23-0": "204030", "23-1": "Customer unable to pay.", "23-2": "200" }, "cols": 3, "rows": 24 } [/block] [block:api-header] { "type": "basic", "title": "Orange billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "100000", "1-0": "210100", "2-0": "200120", "0-1": "Transaction successfully completed", "0-2": "100", "1-1": "Price point not available", "1-2": "200", "2-1": "Invalid MSISDN", "2-2": "200", "3-0": "200130", "3-1": "Invalid subscription", "3-2": "200", "4-0": "200140", "4-1": "Invalid charge amount", "4-2": "200", "5-0": "200150", "5-1": "Invalid username/password/IP", "5-2": "200", "6-0": "200160", "6-1": "Invalid product", "6-2": "200", "7-0": "200100", "7-1": "Unmapped transaction failure", "7-2": "200", "8-0": "204010", "8-1": "Daily/monthly credit limit reached", "8-2": "204", "9-0": "204020", "9-1": "Insufficient credit on handset", "9-2": "204" }, "cols": 3, "rows": 10 } [/block] [block:api-header] { "type": "basic", "title": "TMobile billing route" } [/block] Message sending stage [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "210100", "0-1": "Price point not available", "0-2": "200", "1-0": "200120", "1-1": "Invalid message body length (max length 160 chars)", "1-2": "200", "2-0": "200130", "2-1": "Message body missing when not configured as silent billing", "2-2": "200", "3-0": "200140", "3-1": "Validity period exceeds 4320 minutes (144 x 30 minute intervals)", "3-2": "200", "4-0": "200210", "4-1": "Prepay database error", "4-2": "200", "5-0": "200211", "5-1": "Subscriber account suspended", "5-2": "200", "6-0": "200212", "6-1": "MT-Charged SMS not allowed for subscriber", "6-2": "200", "7-0": "200213", "7-1": "Not a customer", "7-2": "200", "8-0": "200214", "8-1": "Customer category not allowed for Third Party (billing transferred to Virgin route)", "8-2": "200", "9-0": "200215", "9-1": "Destination barred by prepay system", "9-2": "200", "10-0": "200216", "10-1": "Prepay system bar", "10-2": "200", "11-0": "200217", "11-1": "Unknown third party", "11-2": "200", "12-0": "200218", "12-1": "Invalid element content", "12-2": "200", "13-0": "200219", "13-1": "Account disabled", "13-2": "200", "14-0": "200220", "14-1": "Ext_reference value have been used in the last 5 minutes", "14-2": "200", "15-0": "200221", "15-1": "Operation not allowed", "15-2": "200", "16-0": "200222", "16-1": "Not a deliverable number", "16-2": "200", "17-0": "200223", "17-1": "Invalid service ID", "17-2": "200", "18-0": "200224", "18-1": "Bad XML document", "18-2": "200", "19-0": "200225", "19-1": "Content lock error", "19-2": "200", "20-0": "200226", "20-1": "Feature query disabled", "20-2": "200", "21-0": "200227", "21-1": "Immediate not allowed", "21-2": "200", "22-0": "200228", "22-1": "Silent message not allowed", "22-2": "200", "23-0": "200229", "23-1": "Replace message not allowed", "23-2": "200", "24-0": "200200", "24-1": "Unmapped transaction failure", "24-2": "200", "25-0": "200510", "25-1": "System failure", "25-2": "200", "26-0": "200511", "26-1": "Queue size is too long", "26-2": "200", "27-0": "200512", "27-1": "Allowed throughput limit reached. Retry later.", "27-2": "200", "28-0": "200513", "28-1": "Customer database error", "28-2": "200", "29-0": "200514", "29-1": "Backend timeout while processing the request", "29-2": "200", "30-0": "204010", "30-1": "No funds", "30-2": "204" }, "cols": 3, "rows": 31 } [/block] Delivery report stage [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related stat", "0-0": "100000", "0-1": "Acknowledged delivery confirmed", "0-2": "100", "1-0": "200310", "1-1": "Delivery failure", "1-2": "200", "2-0": "200311", "2-1": "Delivery not permitted/possible", "2-2": "200", "3-0": "200312", "3-1": "Unknown destination", "3-2": "200", "4-0": "200313", "4-1": "SMSC rejected destination", "4-2": "200", "5-0": "200314", "5-1": "Customer category not allowed for third party", "5-2": "200", "6-0": "200315", "6-1": "Destination invalid", "6-2": "200", "7-0": "200316", "7-1": "Prepay bar", "7-2": "200", "8-0": "200317", "8-1": "Not a deliverable number", "8-2": "200", "9-0": "200318", "9-1": "Content lock error", "9-2": "200", "10-0": "200319", "10-1": "Not a subscriber", "10-2": "200", "11-0": "200320", "11-1": "Reverse billed sms not allowed for subscriber", "11-2": "200", "12-0": "200321", "12-1": "Subscriber account suspended", "12-2": "200", "13-0": "200300", "13-1": "Unmapped transaction failure", "13-2": "200", "14-0": "200610", "14-1": "Destination is detached (switched off)", "14-2": "200", "15-0": "200611", "15-1": "Destination is not responding", "15-2": "200", "16-0": "200612", "16-1": "Error at destination", "16-2": "200", "17-0": "200613", "17-1": "Memory full at destination", "17-2": "200", "18-0": "200614", "18-1": "Unspecified error", "18-2": "200", "19-0": "200615", "19-1": "TPG system failure", "19-2": "200", "20-0": "204010", "20-1": "Insufficient funds", "20-2": "204" }, "cols": 3, "rows": 21 } [/block] [block:api-header] { "type": "basic", "title": "Three billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "100000", "0-1": "Transaction completed succesfully", "0-2": "100", "1-0": "200110", "1-1": "Required billing text descriptor missing", "1-2": "200", "2-0": "200120", "2-1": "Invalid input value", "2-2": "200", "3-0": "200130", "3-1": "Invalid charging information", "3-2": "200", "4-0": "200140", "4-1": "Charge failed", "4-2": "200", "5-0": "200150", "5-1": "Policy error (Thrown in case some policy rule disallows the request)", "5-2": "200", "6-0": "200160", "6-1": "Duplicate charge request", "6-2": "200", "7-0": "200170", "7-1": "Adult verification failed", "7-2": "200", "8-0": "200180", "8-1": "Unable to locate the specified subscriber", "8-2": "200", "9-0": "200190", "9-1": "Subscriber restriction clause has failed", "9-2": "200", "10-0": "200200", "10-1": "Request denied, no service contract found", "10-2": "200", "11-0": "200210", "11-1": "The 3API session indentifier is not valid", "11-2": "200", "12-0": "200100", "12-1": "Unmapped transaction failure", "12-2": "200", "13-0": "200220", "13-1": "Outside payout range (10 - 3000 pence)", "13-2": "200", "14-0": "200510", "14-1": "Service error (Thrown in case when there is an internal error)", "14-2": "200", "15-0": "204010", "15-1": "Subscriber has insufficient funds", "15-2": "204" }, "cols": 3, "rows": 16 } [/block] [block:api-header] { "type": "basic", "title": "Virgin billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "100000", "0-1": "Billing Successful", "0-2": "100", "1-0": "200000", "1-1": "Billing Unsuccessful", "1-2": "200", "2-0": "210100", "2-1": "Tariff Unavailable", "2-2": "210100" }, "cols": 3, "rows": 3 } [/block] [block:api-header] { "type": "basic", "title": "O2 billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "100000", "0-1": "Transaction completed successfully", "0-2": "100", "2-0": "200110", "2-1": "MerchantID value missing", "2-2": "200", "3-0": "200120", "3-1": "The service has been set 'out of service' by the operations team", "3-2": "200", "4-0": "200130", "4-1": "The request is malformed or the header does not contain the required fields.", "4-2": "200", "5-0": "200140", "5-1": "The SOA transaction is not unique", "5-2": "200", "6-0": "200150", "6-1": "The request is malformed or the header does not contain the required fields.", "6-2": "200", "7-0": "200160", "7-1": "The currency code has been provided in the request", "7-2": "200", "8-0": "200170", "8-1": "Subscription identifier is missing or item prices are zero", "8-2": "200", "9-0": "200180", "9-1": "The external ID provided in the request is a duplicate", "9-2": "200", "10-0": "200190", "10-1": "The account provided is invalid (MVNO/O2 Business, billing routed to PSMS)", "10-2": "200", "11-0": "200200", "11-1": "The account provided is not eligible for content events due to a bar", "11-2": "200", "12-0": "200210", "12-1": "The account provided is not allowed to receive the content type specified", "12-2": "200", "13-0": "200220", "13-1": "The value of the transaction exceeds the maximum value allowed by the service", "13-2": "200", "14-0": "200230", "14-1": "A refund using the same externalID has already been received", "14-2": "200", "17-0": "", "17-1": "Unmapped transaction failure", "17-2": "200", "18-0": "200510", "18-1": "A system error has occurred, that cannot be represented by alternative error codes", "18-2": "200", "19-0": "200520", "19-1": "The system is busy, for example throttling limits have been reached", "19-2": "200", "20-0": "204010", "20-1": "Insufficient funds to apply the debit operation", "20-2": "204", "15-0": "200240", "16-0": "200250", "15-1": "O2 Billing limit reached", "15-2": "200", "16-1": "Not attempted on PSMS", "16-2": "200", "1-0": "200100", "1-1": "Undefined/Unavailable tariff", "1-2": "210" }, "cols": 3, "rows": 21 } [/block]
In some cases, ImpulsePay will expose Network Operator status codes to allow merchants to narrow down the cause of an error within each individual network. [block:api-header] { "type": "basic", "title": "Submission Errors" } [/block] [block:parameters] { "data": { "h-0": "Status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "010010", "0-1": "TransID contains invalid characters (A-Z, 0-9 and - only)", "0-2": "N/A", "1-0": "010020", "1-1": "MSISDN not an integer", "1-2": "N/A", "2-0": "010030", "2-1": "Not a valid UK MSISDN", "2-2": "N/A", "3-0": "010040", "3-1": "AccountID not an integer", "3-2": "N/A", "4-0": "010050", "4-1": "RouteID not an integer", "4-2": "N/A", "5-0": "010060", "5-1": "Tariff not an integer", "5-2": "N/A", "6-0": "010070", "6-1": "Alert URL does not start with http(s)://", "6-2": "N/A", "7-0": "010080", "7-1": "TransID does not start with a valid shard date (YYYYMM required)", "7-2": "N/A", "8-0": "010090", "8-1": "ShardDate not set up yet (e.g future date)", "8-2": "N/A", "9-0": "010100", "9-1": "RetryFor is not an integer or less than 0 or greater than 4320", "10-0": "010110", "10-1": "Priority not 1, 2 or 3", "10-2": "N/A", "11-0": "010120", "11-1": "Currency not GBP or EUR", "11-2": "N/A", "12-0": "010130", "12-1": "IsAlive not Y or N", "12-2": "N/A", "13-0": "010140", "13-1": "IsKnown route invalid (not configured in MNOMappings)", "13-2": "N/A", "21-0": "010999", "21-1": "Error adding request (may be duplicate)", "21-2": "N/A", "22-0": "010999", "22-1": "Duplicate billing request", "22-2": "N/A", "23-0": "000000", "23-1": "Initial request accepted and logged (used for internal tracking)", "23-2": "N/A", "24-0": "200000", "24-1": "Forced failed billing attempt", "24-2": "200", "26-0": "010150", "26-1": "Invalid key", "26-2": "N/A", "9-2": "N/A", "14-0": "010150", "14-1": "Key Missing", "14-2": "N/A", "15-0": "010160", "15-1": "Message invalid", "15-2": "N/A", "16-0": "010170", "16-1": "Sender invalid", "16-2": "N/A", "17-0": "010180", "17-1": "Invalid campaign ID", "17-2": "N/A", "18-0": "010200", "18-1": "Invalid Alias", "18-2": "N/A", "19-0": "010210", "19-1": "Not opted in", "19-2": "N/A", "20-0": "010220", "20-1": "Blacklisted", "20-2": "N/A", "25-0": "208000", "25-1": "120 deactivation rule limit reached without consumer reactivation, recurring payment cancelled." }, "cols": 3, "rows": 27 } [/block] [block:api-header] { "type": "basic", "title": "HLR Errors" } [/block] [block:parameters] { "data": { "h-0": "Status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "207000", "0-1": "Connection to Tyntec error", "0-2": "207", "1-0": "207919", "1-1": "Route found, no MNOMapping in place", "1-2": "207" }, "cols": 3, "rows": 2 } [/block] [block:api-header] { "type": "basic", "title": "Vodafone billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "100000", "0-1": "Transaction completed successfully", "0-2": "100", "1-0": "200110", "1-1": "MerchantName or ServiceID not configured for Account", "1-2": "200", "2-0": "200120", "2-1": "opcoReason - Rejected other", "2-2": "200", "3-0": "200130", "3-1": "opcoReason - User not found", "3-2": "200", "4-0": "200140", "4-1": "opcoReason - Denied other", "4-2": "200", "5-0": "200150", "5-1": "opcoReason - Content blocked", "5-2": "200", "6-0": "200160", "6-1": "opcoReason - System error", "6-2": "200", "7-0": "200170", "7-1": "opcoReason - Validation error", "7-2": "200", "8-0": "200180", "8-1": "opcoReason - User barred", "8-2": "200", "9-0": "200190", "9-1": "The transaction ID provided in the operation does not exist.", "9-2": "200", "10-0": "200200", "10-1": "User performs an usage request and does not have a valid subscription.", "10-2": "200", "11-0": "200210", "11-1": "The package does not have any active price points", "11-2": "200", "12-0": "200220", "12-1": "The service ID used is not recognised", "12-2": "200", "13-0": "200100", "13-1": "Unmapped transaction failure", "13-2": "200", "14-0": "200510", "14-1": "Unable to connect to VF gateway", "14-2": "200", "16-0": "200520", "16-1": "Atomic connection error", "16-2": "200", "17-0": "200530", "17-1": "User have a valid subscription but does not have sufficient credits to use the service", "17-2": "200", "18-0": "200540", "18-1": "The payment failed in the billing system, check opcoReason for reason", "18-2": "200", "19-0": "200550", "19-1": "Unrecognised usage complete response", "19-2": "200", "20-0": "200560", "20-1": "Unrecognised usage response", "20-2": "200", "21-0": "204010", "22-0": "204020", "23-0": "204030", "24-0": "204040", "25-0": "", "21-1": "opcoReason - insufficient funds", "21-2": "204", "22-1": "The individual transaction amount partner trading limit has been breached", "22-2": "204", "23-1": "The cumulative transaction amount partner trading limit has been breached", "23-2": "204", "24-1": "A credit or spend limit has been exceeded", "24-2": "204", "15-0": "200511", "15-1": "Connection timeout", "15-2": "200" }, "cols": 3, "rows": 26 } [/block] [block:api-header] { "type": "basic", "title": "EE billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay status", "0-0": "200410", "0-1": "Retrieve Failed. Shown if failed to receive data from the server", "0-2": "200", "1-0": "200412", "1-1": "Insert of updated failed. Shown if the service failed to insert of update the database table", "1-2": "200", "2-0": "200414", "2-1": "Technical Exception. Technical fault thrown by the XTC client", "2-2": "200", "3-0": "200416", "3-1": "Service Unavailable. Thrown if the customer brand is not orange UK.", "3-2": "200", "4-0": "200418", "4-1": "Charge not found. If the the charge is not found for the given subscription ID and phase.", "4-2": "200", "5-0": "200420", "5-1": "Invalid input. The provided input is not valid.", "5-2": "200", "6-0": "200422", "6-1": "Exception in remote service. Thrown if business fault is thrown from a downstream system.", "6-2": "200", "7-0": "200424", "7-1": "Vat code not found.", "7-2": "200", "8-0": "200426", "8-1": "Subscription type not found for the given subscription ID.", "8-2": "200", "9-0": "200428", "9-1": "XTC unknown. Business fault thrown by the XTC client.", "9-2": "200", "10-0": "200430", "10-1": "XTC invalid data. Business fault thrown by the XTC client.", "10-2": "200", "11-0": "200432", "11-1": "Charge customer available. Wrapped business fault for the technical exception code UNKNOWN thrown by the BEM client.", "11-2": "200", "12-0": "200434", "12-1": "Charge band not found. When we are unable to retrieve charge band by subscription ID and the subscription phase.", "12-2": "200", "13-0": "200436", "13-1": "Product charge not configured.", "13-2": "200", "14-0": "200438", "14-1": "Product charge is already configured.", "14-2": "200", "15-0": "200440", "15-1": "Vender not authorised.", "15-2": "200", "16-0": "200442", "16-1": "Subscription details not found.", "16-2": "200", "17-0": "200444", "17-1": "Referrer not found for the corresponding sender in the eiMessageContext.", "17-2": "200", "18-0": "200446", "18-1": "Exception in charging system.", "18-2": "200", "19-0": "200448", "19-1": "Invalid input.", "19-2": "200", "20-0": "200450", "20-1": "Paym account not found. Exception thrown from getpaymaccount web service.", "20-2": "200", "21-0": "200452", "21-1": "Get paym account unavailable.", "21-2": "200", "22-0": "200454", "22-1": "Exception in remote service. Unknown exception thrown from getpaymaccount web service.", "22-2": "200", "23-0": "204030", "23-1": "Customer unable to pay.", "23-2": "200" }, "cols": 3, "rows": 24 } [/block] [block:api-header] { "type": "basic", "title": "Orange billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "100000", "1-0": "210100", "2-0": "200120", "0-1": "Transaction successfully completed", "0-2": "100", "1-1": "Price point not available", "1-2": "200", "2-1": "Invalid MSISDN", "2-2": "200", "3-0": "200130", "3-1": "Invalid subscription", "3-2": "200", "4-0": "200140", "4-1": "Invalid charge amount", "4-2": "200", "5-0": "200150", "5-1": "Invalid username/password/IP", "5-2": "200", "6-0": "200160", "6-1": "Invalid product", "6-2": "200", "7-0": "200100", "7-1": "Unmapped transaction failure", "7-2": "200", "8-0": "204010", "8-1": "Daily/monthly credit limit reached", "8-2": "204", "9-0": "204020", "9-1": "Insufficient credit on handset", "9-2": "204" }, "cols": 3, "rows": 10 } [/block] [block:api-header] { "type": "basic", "title": "TMobile billing route" } [/block] Message sending stage [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "210100", "0-1": "Price point not available", "0-2": "200", "1-0": "200120", "1-1": "Invalid message body length (max length 160 chars)", "1-2": "200", "2-0": "200130", "2-1": "Message body missing when not configured as silent billing", "2-2": "200", "3-0": "200140", "3-1": "Validity period exceeds 4320 minutes (144 x 30 minute intervals)", "3-2": "200", "4-0": "200210", "4-1": "Prepay database error", "4-2": "200", "5-0": "200211", "5-1": "Subscriber account suspended", "5-2": "200", "6-0": "200212", "6-1": "MT-Charged SMS not allowed for subscriber", "6-2": "200", "7-0": "200213", "7-1": "Not a customer", "7-2": "200", "8-0": "200214", "8-1": "Customer category not allowed for Third Party (billing transferred to Virgin route)", "8-2": "200", "9-0": "200215", "9-1": "Destination barred by prepay system", "9-2": "200", "10-0": "200216", "10-1": "Prepay system bar", "10-2": "200", "11-0": "200217", "11-1": "Unknown third party", "11-2": "200", "12-0": "200218", "12-1": "Invalid element content", "12-2": "200", "13-0": "200219", "13-1": "Account disabled", "13-2": "200", "14-0": "200220", "14-1": "Ext_reference value have been used in the last 5 minutes", "14-2": "200", "15-0": "200221", "15-1": "Operation not allowed", "15-2": "200", "16-0": "200222", "16-1": "Not a deliverable number", "16-2": "200", "17-0": "200223", "17-1": "Invalid service ID", "17-2": "200", "18-0": "200224", "18-1": "Bad XML document", "18-2": "200", "19-0": "200225", "19-1": "Content lock error", "19-2": "200", "20-0": "200226", "20-1": "Feature query disabled", "20-2": "200", "21-0": "200227", "21-1": "Immediate not allowed", "21-2": "200", "22-0": "200228", "22-1": "Silent message not allowed", "22-2": "200", "23-0": "200229", "23-1": "Replace message not allowed", "23-2": "200", "24-0": "200200", "24-1": "Unmapped transaction failure", "24-2": "200", "25-0": "200510", "25-1": "System failure", "25-2": "200", "26-0": "200511", "26-1": "Queue size is too long", "26-2": "200", "27-0": "200512", "27-1": "Allowed throughput limit reached. Retry later.", "27-2": "200", "28-0": "200513", "28-1": "Customer database error", "28-2": "200", "29-0": "200514", "29-1": "Backend timeout while processing the request", "29-2": "200", "30-0": "204010", "30-1": "No funds", "30-2": "204" }, "cols": 3, "rows": 31 } [/block] Delivery report stage [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related stat", "0-0": "100000", "0-1": "Acknowledged delivery confirmed", "0-2": "100", "1-0": "200310", "1-1": "Delivery failure", "1-2": "200", "2-0": "200311", "2-1": "Delivery not permitted/possible", "2-2": "200", "3-0": "200312", "3-1": "Unknown destination", "3-2": "200", "4-0": "200313", "4-1": "SMSC rejected destination", "4-2": "200", "5-0": "200314", "5-1": "Customer category not allowed for third party", "5-2": "200", "6-0": "200315", "6-1": "Destination invalid", "6-2": "200", "7-0": "200316", "7-1": "Prepay bar", "7-2": "200", "8-0": "200317", "8-1": "Not a deliverable number", "8-2": "200", "9-0": "200318", "9-1": "Content lock error", "9-2": "200", "10-0": "200319", "10-1": "Not a subscriber", "10-2": "200", "11-0": "200320", "11-1": "Reverse billed sms not allowed for subscriber", "11-2": "200", "12-0": "200321", "12-1": "Subscriber account suspended", "12-2": "200", "13-0": "200300", "13-1": "Unmapped transaction failure", "13-2": "200", "14-0": "200610", "14-1": "Destination is detached (switched off)", "14-2": "200", "15-0": "200611", "15-1": "Destination is not responding", "15-2": "200", "16-0": "200612", "16-1": "Error at destination", "16-2": "200", "17-0": "200613", "17-1": "Memory full at destination", "17-2": "200", "18-0": "200614", "18-1": "Unspecified error", "18-2": "200", "19-0": "200615", "19-1": "TPG system failure", "19-2": "200", "20-0": "204010", "20-1": "Insufficient funds", "20-2": "204" }, "cols": 3, "rows": 21 } [/block] [block:api-header] { "type": "basic", "title": "Three billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "100000", "0-1": "Transaction completed succesfully", "0-2": "100", "1-0": "200110", "1-1": "Required billing text descriptor missing", "1-2": "200", "2-0": "200120", "2-1": "Invalid input value", "2-2": "200", "3-0": "200130", "3-1": "Invalid charging information", "3-2": "200", "4-0": "200140", "4-1": "Charge failed", "4-2": "200", "5-0": "200150", "5-1": "Policy error (Thrown in case some policy rule disallows the request)", "5-2": "200", "6-0": "200160", "6-1": "Duplicate charge request", "6-2": "200", "7-0": "200170", "7-1": "Adult verification failed", "7-2": "200", "8-0": "200180", "8-1": "Unable to locate the specified subscriber", "8-2": "200", "9-0": "200190", "9-1": "Subscriber restriction clause has failed", "9-2": "200", "10-0": "200200", "10-1": "Request denied, no service contract found", "10-2": "200", "11-0": "200210", "11-1": "The 3API session indentifier is not valid", "11-2": "200", "12-0": "200100", "12-1": "Unmapped transaction failure", "12-2": "200", "13-0": "200220", "13-1": "Outside payout range (10 - 3000 pence)", "13-2": "200", "14-0": "200510", "14-1": "Service error (Thrown in case when there is an internal error)", "14-2": "200", "15-0": "204010", "15-1": "Subscriber has insufficient funds", "15-2": "204" }, "cols": 3, "rows": 16 } [/block] [block:api-header] { "type": "basic", "title": "Virgin billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "100000", "0-1": "Billing Successful", "0-2": "100", "1-0": "200000", "1-1": "Billing Unsuccessful", "1-2": "200", "2-0": "210100", "2-1": "Tariff Unavailable", "2-2": "210100" }, "cols": 3, "rows": 3 } [/block] [block:api-header] { "type": "basic", "title": "O2 billing route" } [/block] [block:parameters] { "data": { "h-0": "Operator status code", "h-1": "Description", "h-2": "ImpulsePay related status", "0-0": "100000", "0-1": "Transaction completed successfully", "0-2": "100", "2-0": "200110", "2-1": "MerchantID value missing", "2-2": "200", "3-0": "200120", "3-1": "The service has been set 'out of service' by the operations team", "3-2": "200", "4-0": "200130", "4-1": "The request is malformed or the header does not contain the required fields.", "4-2": "200", "5-0": "200140", "5-1": "The SOA transaction is not unique", "5-2": "200", "6-0": "200150", "6-1": "The request is malformed or the header does not contain the required fields.", "6-2": "200", "7-0": "200160", "7-1": "The currency code has been provided in the request", "7-2": "200", "8-0": "200170", "8-1": "Subscription identifier is missing or item prices are zero", "8-2": "200", "9-0": "200180", "9-1": "The external ID provided in the request is a duplicate", "9-2": "200", "10-0": "200190", "10-1": "The account provided is invalid (MVNO/O2 Business, billing routed to PSMS)", "10-2": "200", "11-0": "200200", "11-1": "The account provided is not eligible for content events due to a bar", "11-2": "200", "12-0": "200210", "12-1": "The account provided is not allowed to receive the content type specified", "12-2": "200", "13-0": "200220", "13-1": "The value of the transaction exceeds the maximum value allowed by the service", "13-2": "200", "14-0": "200230", "14-1": "A refund using the same externalID has already been received", "14-2": "200", "17-0": "", "17-1": "Unmapped transaction failure", "17-2": "200", "18-0": "200510", "18-1": "A system error has occurred, that cannot be represented by alternative error codes", "18-2": "200", "19-0": "200520", "19-1": "The system is busy, for example throttling limits have been reached", "19-2": "200", "20-0": "204010", "20-1": "Insufficient funds to apply the debit operation", "20-2": "204", "15-0": "200240", "16-0": "200250", "15-1": "O2 Billing limit reached", "15-2": "200", "16-1": "Not attempted on PSMS", "16-2": "200", "1-0": "200100", "1-1": "Undefined/Unavailable tariff", "1-2": "210" }, "cols": 3, "rows": 21 } [/block]
{"__v":115,"_id":"554cec9cde67270d009b029d","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"url":""},"body":"This guide explains step by step the process of getting a payment page integrated, configured and set live.\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Before starting\",\n  \"body\": \"Merchants will need a username and password to access the [ImpulsePay Dashboard](http://dashboard.impulsepay.com)\",\n  \"sidebar\": true\n}\n[/block]\nThis guide covers the two parts needed to get started:\n- Choosing, customising and submitting a Payment Page for approval\n- Configuring the service URL\n\nFirstly, merchants should set up their Payment Page using the Edit Payment Page tool.\n**1. **Log in to the [ImpulsePay Dashboard](http://dashboard.impulsepay.com). \n\n**2. **Click on **Edit Payment Pages** at the top of the dashboard. This will bring up the Payment Page selection screen, which contains templates and saved Payment Pages . \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Creating a Payment Page\"\n}\n[/block]\n**3. **Click **Create New** to open a blank Payment Page, or click **Select** on a template to open the Editor tool to customise. \n\n**4. **Enter a name for the Payment Page in the **Payment Page Name** field. This name will be used to identify the page within the Settings and API calls.\n\n**5. **Next, enter HTML code or edit the template code as required. Any images or CSS files should be uploaded using the **Upload Images and CSS Files** tool underneath the Editor window.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Adding a Purchase Button\"\n}\n[/block]\n**6. **Place the cursor where the Purchase Button is to be inserted. Click **Add Purchase Button** to launch the button wizard. \n\n**7. **Enter a **Friendly name** for the service. This is used to identify the button in API calls. Then select a **Charge Amount**, which should be between £1 and £30. **Access Period** can be left blank if there are no time-based requirements for the service.\n\n**8. **Next, set **MNVO failure amount**. This can be used to charge a consumer the failover amount in cases where the Charge Amount price point is not available on Virgin, O2 Business, Tesco and GiffGaff.\n\n**9. ** Enter the **call to action** for both Purchase Buttons and select the colours for each. Ensure that the colour contrast remains above 2:1. \n\n**10. **Optionally, a recurring payment can be configured by changing the billing frequency. Leave **free trial period** blank if not required.\n\n**11. **To finish, click **Add Purchase Button** to insert the button code into the HTML.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Preview Payment Page\"\n}\n[/block]\n**12. **To preview the Payment Page, click **Save as Draft**. Then click **Preview Link** to open the Payment Page in a new tab. If the page generates a descriptive error, use the Editor to correct the problem, then click **Save as Draft** and **Preview Link**. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Submitting for approval\"\n}\n[/block]\n**13. **Click **Submit for Approval** when the Payment Page is finished.\n\nThe Payment Page will then appear within the **Pending Approval** section on the template selection screen. Once the payment page has been approved, it will appear in the **Approved **section. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Creating a RouteID\"\n}\n[/block]\n**14. **Before this Payment Page can be set live, additional configuration is required. On the Dashboard homepage, select **Create RouteID**. \n\n**15. **Enter a **Service Name**. This is used to identify the service in receipt and reminder messages sent to consumers.\n\n**16. **Enter a [Success URL](doc:success-url-api) and [Failure URL](doc:failure-url-api)  and configure other notification and alert URLs. Then select preferences for flow verification methods and preferences for each Additional Route Setting.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Configure Payment Pages for devices\"\n}\n[/block]\n**17. **Use the Checkout Configurator to select **approved** payment pages for each device type in Route A. Route B can be used to select a secondary template for each device, if A/B split testing is required. To only use one template, simply leave Route B unselected. \n\n**18. **To complete setup, select **Save Changes.** \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Create Service URL\"\n}\n[/block]\n**19. **To setup a custom domain name, contact the domain registrar to create a CNAME record pointing to the domain provided by ImpulsePay. \n\n**20. ** To launch the service, construct the Service URL using the following format:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://m.domain.com/{RouteID}/{CampaignID}?URLKey={URLKey}\",\n      \"language\": \"http\"\n    }\n  ]\n}\n[/block]\nThe RouteID parameter is the ServiceURLRouteID found at the top of the Settings page along with the URLKey. CampaignID is a custom parameter set by the merchant to uniquely identify this service. \n\nThis service is now live. To view usage figures, visit the detailed stats page on the Dashboard.","category":"554ced01374fec0d007e62ff","createdAt":"2015-05-08T17:04:28.574Z","excerpt":"","githubsync":"","hidden":false,"link_external":false,"link_url":"","order":0,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"setting-up-a-service-1","sync_unique":"","title":"Getting Set Up","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Getting Set Up


This guide explains step by step the process of getting a payment page integrated, configured and set live. [block:callout] { "type": "warning", "title": "Before starting", "body": "Merchants will need a username and password to access the [ImpulsePay Dashboard](http://dashboard.impulsepay.com)", "sidebar": true } [/block] This guide covers the two parts needed to get started: - Choosing, customising and submitting a Payment Page for approval - Configuring the service URL Firstly, merchants should set up their Payment Page using the Edit Payment Page tool. **1. **Log in to the [ImpulsePay Dashboard](http://dashboard.impulsepay.com). **2. **Click on **Edit Payment Pages** at the top of the dashboard. This will bring up the Payment Page selection screen, which contains templates and saved Payment Pages . [block:api-header] { "type": "basic", "title": "Creating a Payment Page" } [/block] **3. **Click **Create New** to open a blank Payment Page, or click **Select** on a template to open the Editor tool to customise. **4. **Enter a name for the Payment Page in the **Payment Page Name** field. This name will be used to identify the page within the Settings and API calls. **5. **Next, enter HTML code or edit the template code as required. Any images or CSS files should be uploaded using the **Upload Images and CSS Files** tool underneath the Editor window. [block:api-header] { "type": "basic", "title": "Adding a Purchase Button" } [/block] **6. **Place the cursor where the Purchase Button is to be inserted. Click **Add Purchase Button** to launch the button wizard. **7. **Enter a **Friendly name** for the service. This is used to identify the button in API calls. Then select a **Charge Amount**, which should be between £1 and £30. **Access Period** can be left blank if there are no time-based requirements for the service. **8. **Next, set **MNVO failure amount**. This can be used to charge a consumer the failover amount in cases where the Charge Amount price point is not available on Virgin, O2 Business, Tesco and GiffGaff. **9. ** Enter the **call to action** for both Purchase Buttons and select the colours for each. Ensure that the colour contrast remains above 2:1. **10. **Optionally, a recurring payment can be configured by changing the billing frequency. Leave **free trial period** blank if not required. **11. **To finish, click **Add Purchase Button** to insert the button code into the HTML. [block:api-header] { "type": "basic", "title": "Preview Payment Page" } [/block] **12. **To preview the Payment Page, click **Save as Draft**. Then click **Preview Link** to open the Payment Page in a new tab. If the page generates a descriptive error, use the Editor to correct the problem, then click **Save as Draft** and **Preview Link**. [block:api-header] { "type": "basic", "title": "Submitting for approval" } [/block] **13. **Click **Submit for Approval** when the Payment Page is finished. The Payment Page will then appear within the **Pending Approval** section on the template selection screen. Once the payment page has been approved, it will appear in the **Approved **section. [block:api-header] { "type": "basic", "title": "Creating a RouteID" } [/block] **14. **Before this Payment Page can be set live, additional configuration is required. On the Dashboard homepage, select **Create RouteID**. **15. **Enter a **Service Name**. This is used to identify the service in receipt and reminder messages sent to consumers. **16. **Enter a [Success URL](doc:success-url-api) and [Failure URL](doc:failure-url-api) and configure other notification and alert URLs. Then select preferences for flow verification methods and preferences for each Additional Route Setting. [block:api-header] { "type": "basic", "title": "Configure Payment Pages for devices" } [/block] **17. **Use the Checkout Configurator to select **approved** payment pages for each device type in Route A. Route B can be used to select a secondary template for each device, if A/B split testing is required. To only use one template, simply leave Route B unselected. **18. **To complete setup, select **Save Changes.** [block:api-header] { "type": "basic", "title": "Create Service URL" } [/block] **19. **To setup a custom domain name, contact the domain registrar to create a CNAME record pointing to the domain provided by ImpulsePay. **20. ** To launch the service, construct the Service URL using the following format: [block:code] { "codes": [ { "code": "http://m.domain.com/{RouteID}/{CampaignID}?URLKey={URLKey}", "language": "http" } ] } [/block] The RouteID parameter is the ServiceURLRouteID found at the top of the Settings page along with the URLKey. CampaignID is a custom parameter set by the merchant to uniquely identify this service. This service is now live. To view usage figures, visit the detailed stats page on the Dashboard.
This guide explains step by step the process of getting a payment page integrated, configured and set live. [block:callout] { "type": "warning", "title": "Before starting", "body": "Merchants will need a username and password to access the [ImpulsePay Dashboard](http://dashboard.impulsepay.com)", "sidebar": true } [/block] This guide covers the two parts needed to get started: - Choosing, customising and submitting a Payment Page for approval - Configuring the service URL Firstly, merchants should set up their Payment Page using the Edit Payment Page tool. **1. **Log in to the [ImpulsePay Dashboard](http://dashboard.impulsepay.com). **2. **Click on **Edit Payment Pages** at the top of the dashboard. This will bring up the Payment Page selection screen, which contains templates and saved Payment Pages . [block:api-header] { "type": "basic", "title": "Creating a Payment Page" } [/block] **3. **Click **Create New** to open a blank Payment Page, or click **Select** on a template to open the Editor tool to customise. **4. **Enter a name for the Payment Page in the **Payment Page Name** field. This name will be used to identify the page within the Settings and API calls. **5. **Next, enter HTML code or edit the template code as required. Any images or CSS files should be uploaded using the **Upload Images and CSS Files** tool underneath the Editor window. [block:api-header] { "type": "basic", "title": "Adding a Purchase Button" } [/block] **6. **Place the cursor where the Purchase Button is to be inserted. Click **Add Purchase Button** to launch the button wizard. **7. **Enter a **Friendly name** for the service. This is used to identify the button in API calls. Then select a **Charge Amount**, which should be between £1 and £30. **Access Period** can be left blank if there are no time-based requirements for the service. **8. **Next, set **MNVO failure amount**. This can be used to charge a consumer the failover amount in cases where the Charge Amount price point is not available on Virgin, O2 Business, Tesco and GiffGaff. **9. ** Enter the **call to action** for both Purchase Buttons and select the colours for each. Ensure that the colour contrast remains above 2:1. **10. **Optionally, a recurring payment can be configured by changing the billing frequency. Leave **free trial period** blank if not required. **11. **To finish, click **Add Purchase Button** to insert the button code into the HTML. [block:api-header] { "type": "basic", "title": "Preview Payment Page" } [/block] **12. **To preview the Payment Page, click **Save as Draft**. Then click **Preview Link** to open the Payment Page in a new tab. If the page generates a descriptive error, use the Editor to correct the problem, then click **Save as Draft** and **Preview Link**. [block:api-header] { "type": "basic", "title": "Submitting for approval" } [/block] **13. **Click **Submit for Approval** when the Payment Page is finished. The Payment Page will then appear within the **Pending Approval** section on the template selection screen. Once the payment page has been approved, it will appear in the **Approved **section. [block:api-header] { "type": "basic", "title": "Creating a RouteID" } [/block] **14. **Before this Payment Page can be set live, additional configuration is required. On the Dashboard homepage, select **Create RouteID**. **15. **Enter a **Service Name**. This is used to identify the service in receipt and reminder messages sent to consumers. **16. **Enter a [Success URL](doc:success-url-api) and [Failure URL](doc:failure-url-api) and configure other notification and alert URLs. Then select preferences for flow verification methods and preferences for each Additional Route Setting. [block:api-header] { "type": "basic", "title": "Configure Payment Pages for devices" } [/block] **17. **Use the Checkout Configurator to select **approved** payment pages for each device type in Route A. Route B can be used to select a secondary template for each device, if A/B split testing is required. To only use one template, simply leave Route B unselected. **18. **To complete setup, select **Save Changes.** [block:api-header] { "type": "basic", "title": "Create Service URL" } [/block] **19. **To setup a custom domain name, contact the domain registrar to create a CNAME record pointing to the domain provided by ImpulsePay. **20. ** To launch the service, construct the Service URL using the following format: [block:code] { "codes": [ { "code": "http://m.domain.com/{RouteID}/{CampaignID}?URLKey={URLKey}", "language": "http" } ] } [/block] The RouteID parameter is the ServiceURLRouteID found at the top of the Settings page along with the URLKey. CampaignID is a custom parameter set by the merchant to uniquely identify this service. This service is now live. To view usage figures, visit the detailed stats page on the Dashboard.
{"__v":3,"_id":"57174fc04b807b0e0040ef16","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"Merchants are able to use ImpulsePay's robust verification as a third party tool for their PSMS services, which includes a screenshot at the point of purchase and other verification details. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Hybrid PSMS Robust Verification Template Format\"\n}\n[/block]\nMerchant should follow the following template format to use the hybrid PSMS verification flow. \n\nThe button tag must be contained within a form element that has an ID of PFIForm. Once the pin verification is completed, the form will be submitted to allow you to process the users request.\n\nThe template should use the following code:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<form method=\\\"get\\\" action=\\\"http://yoursite.com/page\\\" id=\\\"PFIForm\\\">\\n <button type=\\\"psms-hybrid\\\" \\n  data-friendlyname=\\\"my comp\\\"\\n  data-shortcode=\\\"89365\\\"\\n  data-msisdnInstruction=\\\"enter number\\\"\\n  data-msisdnInputID=\\\"abc1\\\"\\n  data-msisdnButton=\\\"click me\\\"\\n  data-pinInstruction=\\\"enter pin\\\"\\n  data-pinInputID=“def2”\\n  data-pinButton=\\\"click this\\\"\\n  data-smsSender=\\\"89365\\\"      \\n  data-smsBody=\\\"#pin# or #keyword#\\\">\\n </button>\\n</form>\",\n      \"language\": \"html\"\n    }\n  ]\n}\n[/block]\nThis will create a form object for the MSISDN and Pin entry details which can then be styled and referenced via CSS.\n\nDuring the process, the following javascript functions will also be called:\n\n1. After user enters their MSISDN: \n - The function hybridMSISDN(ButtonID) will be called, which is used to check the MSISDN is valid. \n\n2. After request to send SMS: \n - The function hybridMSISDNError(ButtonID, response) will be called, which will provide the reason for any errors during sending. \n \nError responses for this function are as follows:\nExceededMaxMSISDN => max 3 attempts have been exceeded\nMSISDNWait => less than 60 seconds between attempts to send a pin code\nsuccess => pin was successfully sent\n\n3. After user enters PIN:\n  - hybridPIN(buttonID) will be called, which can be used to validate the pin code\n\n4. After request to check pin: \n  - hybridPinError(ButtonID, response) will be called, which provides any errors during the pincode validation. \n  \nError responses for this function are as follows:\nExceededMaxPin => max 3 attempts exceeded\nPinWait => less than 60 seconds during attempts\nsuccess => pin code is valid\nfailed => pin code is incorrect\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Hybrid PSMS Robust Verification Lookup API\"\n}\n[/block]\nWhen the user submits the Hybrid form, the PWID and pin code parameters are passed to the form.\n \nThe following API can be used to check they are valid:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://bill.impulsepay.com/checkhybrid?PWID=&Pincode=\",\n      \"language\": \"http\"\n    }\n  ]\n}\n[/block]\nAlternatively you can call this API if the user sends an MO message in:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://bill.impulsepay.com/checkhybrid?MSISDN=&Keyword=&Shortcode=\",\n      \"language\": \"http\"\n    }\n  ]\n}\n[/block]\nThe following response parameters can be expected in a JSON format: \n[block:parameters]\n{\n  \"data\": {\n    \"0-0\": \"PWID\",\n    \"1-0\": \"CampaignID\",\n    \"2-0\": \"Note\",\n    \"3-0\": \"AffiliateID\",\n    \"4-0\": \"UserAgent\",\n    \"5-0\": \"URLReferer\",\n    \"6-0\": \"AccessURL\",\n    \"7-0\": \"TemplateID\",\n    \"8-0\": \"TemplateName\",\n    \"9-0\": \"Logged\",\n    \"10-0\": \"ScreenshotURL\",\n    \"11-0\": \"MSISDN\",\n    \"0-1\": \"A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.\",\n    \"2-1\": \"Merchant specific parameters\",\n    \"1-1\": \"The CampaignID specified for this request\",\n    \"3-1\": \"Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.\",\n    \"4-1\": \"The user agent type for which the transaction was processed for\",\n    \"5-1\": \"The URL referrer or SMS message text used to access service (when known)\",\n    \"6-1\": \"The URL the consumer has used to access the service\",\n    \"7-1\": \"Unique 60 character ID displayed to the consumer\",\n    \"8-1\": \"The saved name of the template displayed to the consumer\",\n    \"9-1\": \"Timestamp of when the page was served to the consumer\",\n    \"10-1\": \"URL to the screenshot taken for this transaction.\",\n    \"11-1\": \"The mobile number of the user\",\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\"\n  },\n  \"cols\": 2,\n  \"rows\": 12\n}\n[/block]\nThese lookup requests can be made up to 72 hours after the transaction.\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Error\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"Invalid\",\n    \"1-0\": \"Invalid MSISDN\",\n    \"2-0\": \"Invalid Shortcode\",\n    \"3-0\": \"Invalid Keyword\",\n    \"4-0\": \"Invalid Message\",\n    \"5-0\": \"Invalid Shortcode\",\n    \"6-0\": \"Invalid Pin\",\n    \"7-0\": \"Expired\",\n    \"0-1\": \"API Key is missing\",\n    \"1-1\": \"MSISDN parameter is missing\",\n    \"2-1\": \"Shortcode parameter is missing\",\n    \"3-1\": \"Keyword is missing, or MSISDN matched but keyword did not match.\",\n    \"4-1\": \"No MO message was found\",\n    \"5-1\": \"MSISDN matched, but shortcode did not\",\n    \"6-1\": \"Pincode did not match\",\n    \"7-1\": \"Request is over 72 hours old\"\n  },\n  \"cols\": 2,\n  \"rows\": 8\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"MO PSMS Robust Verification Template Format\"\n}\n[/block]\nThe following template format overrides all existing Payforit functionality as expected on the usual payforit flow. \n\nPages, once submitted, will still need to undergo the usual approval processes, however this is limited to ImpulsePay’s approval only.\n\nTo create a button, use the following code:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<button type=\\\"psms-mo\\\" \\n  data-friendlyname=“my comp”\\n  data-shortcode=\\\"89365\\\"\\n  data-body=\\\"#keyword# to win something #UUID#”><div>some html</div>\\n</button>\",\n      \"language\": \"html\"\n    }\n  ]\n}\n[/block]\nAlthough this uses a button format, it will actually create an HREF tag.\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"Friendlyname\",\n    \"0-1\": \"Unique identifier for this button\",\n    \"1-0\": \"Shortcode\",\n    \"1-1\": \"The shortcode number that the MO should be sent to\",\n    \"2-0\": \"Body\",\n    \"2-1\": \"SMS body for the message. Use #keyword# as placeholder for where the keyword should go and #UUID# for where the unique entry code goes (which is a shortened version of the PWID). UUID consist for a base36 shortID (5 chars), ‘-‘ and a 5 character salt.\"\n  },\n  \"cols\": 2,\n  \"rows\": 3\n}\n[/block]\nThe HTML code within the button tag will be encapsulated within the output tag.\n\nThe keyword should be passed by the merchant via the ServiceURL as ‘KW’.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"MO PSMS UUID Lookup\"\n}\n[/block]\nA new API has been created to look up the UUID value for a session:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"http://bill.impulsepay.com/checkpwid?smsid=&Key=\",\n      \"language\": \"http\"\n    }\n  ]\n}\n[/block]\n\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"SMSID\",\n    \"0-1\": \"The SMSID received in the consumers message\",\n    \"1-0\": \"Key\",\n    \"1-1\": \"The API Key for the account\"\n  },\n  \"cols\": 2,\n  \"rows\": 2\n}\n[/block]\n\nThe following response parameters can be expected in a JSON format: \n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Parameter\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"PWID\",\n    \"1-0\": \"CampaignID\",\n    \"2-0\": \"Note\",\n    \"3-0\": \"AffiliateID\",\n    \"4-0\": \"UserAgent\",\n    \"5-0\": \"URLReferer\",\n    \"6-0\": \"AccessURL\",\n    \"7-0\": \"TemplateID\",\n    \"8-0\": \"TemplateName\",\n    \"9-0\": \"Logged\",\n    \"10-0\": \"ScreenshotURL\",\n    \"0-1\": \"A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.\",\n    \"1-1\": \"The CampaignID specified for this request\",\n    \"2-1\": \"Merchant specific parameters\",\n    \"3-1\": \"Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.\",\n    \"4-1\": \"The user agent type for which the transaction was processed for\",\n    \"5-1\": \"The URL referrer or SMS message text used to access service (when known)\",\n    \"6-1\": \"The URL the consumer has used to access the service\",\n    \"7-1\": \"Unique 60 character ID displayed to the consumer\",\n    \"8-1\": \"The saved name of the template displayed to the consumer\",\n    \"9-1\": \"Timestamp of when the page was served to the consumer\",\n    \"10-1\": \"URL to the screenshot taken for this transaction.\"\n  },\n  \"cols\": 2,\n  \"rows\": 11\n}\n[/block]\nThis request can be made up to 72 hours after the transaction.\n\nThe log is stored with instance access for 6 months then delayed access for 18 months after (for a total period of 2 years).","category":"571748a34b807b0e0040eeff","createdAt":"2016-04-20T09:45:36.381Z","excerpt":"","githubsync":"","hidden":false,"isReference":false,"link_external":false,"link_url":"","order":0,"parentDoc":null,"project":"54eb3720df7add210007b257","slug":"using-robust-verification-api","sync_unique":"","title":"Using Robust Verification API","type":"basic","updates":[],"user":"54eb0de5f863c80d00705f29","version":"5524f5bbd919032b0057ac33","childrenPages":[]}

Using Robust Verification API


Merchants are able to use ImpulsePay's robust verification as a third party tool for their PSMS services, which includes a screenshot at the point of purchase and other verification details. [block:api-header] { "type": "basic", "title": "Hybrid PSMS Robust Verification Template Format" } [/block] Merchant should follow the following template format to use the hybrid PSMS verification flow. The button tag must be contained within a form element that has an ID of PFIForm. Once the pin verification is completed, the form will be submitted to allow you to process the users request. The template should use the following code: [block:code] { "codes": [ { "code": "<form method=\"get\" action=\"http://yoursite.com/page\" id=\"PFIForm\">\n <button type=\"psms-hybrid\" \n data-friendlyname=\"my comp\"\n data-shortcode=\"89365\"\n data-msisdnInstruction=\"enter number\"\n data-msisdnInputID=\"abc1\"\n data-msisdnButton=\"click me\"\n data-pinInstruction=\"enter pin\"\n data-pinInputID=“def2”\n data-pinButton=\"click this\"\n data-smsSender=\"89365\" \n data-smsBody=\"#pin# or #keyword#\">\n </button>\n</form>", "language": "html" } ] } [/block] This will create a form object for the MSISDN and Pin entry details which can then be styled and referenced via CSS. During the process, the following javascript functions will also be called: 1. After user enters their MSISDN: - The function hybridMSISDN(ButtonID) will be called, which is used to check the MSISDN is valid. 2. After request to send SMS: - The function hybridMSISDNError(ButtonID, response) will be called, which will provide the reason for any errors during sending. Error responses for this function are as follows: ExceededMaxMSISDN => max 3 attempts have been exceeded MSISDNWait => less than 60 seconds between attempts to send a pin code success => pin was successfully sent 3. After user enters PIN: - hybridPIN(buttonID) will be called, which can be used to validate the pin code 4. After request to check pin: - hybridPinError(ButtonID, response) will be called, which provides any errors during the pincode validation. Error responses for this function are as follows: ExceededMaxPin => max 3 attempts exceeded PinWait => less than 60 seconds during attempts success => pin code is valid failed => pin code is incorrect [block:api-header] { "type": "basic", "title": "Hybrid PSMS Robust Verification Lookup API" } [/block] When the user submits the Hybrid form, the PWID and pin code parameters are passed to the form. The following API can be used to check they are valid: [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/checkhybrid?PWID=&Pincode=", "language": "http" } ] } [/block] Alternatively you can call this API if the user sends an MO message in: [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/checkhybrid?MSISDN=&Keyword=&Shortcode=", "language": "http" } ] } [/block] The following response parameters can be expected in a JSON format: [block:parameters] { "data": { "0-0": "PWID", "1-0": "CampaignID", "2-0": "Note", "3-0": "AffiliateID", "4-0": "UserAgent", "5-0": "URLReferer", "6-0": "AccessURL", "7-0": "TemplateID", "8-0": "TemplateName", "9-0": "Logged", "10-0": "ScreenshotURL", "11-0": "MSISDN", "0-1": "A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.", "2-1": "Merchant specific parameters", "1-1": "The CampaignID specified for this request", "3-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "4-1": "The user agent type for which the transaction was processed for", "5-1": "The URL referrer or SMS message text used to access service (when known)", "6-1": "The URL the consumer has used to access the service", "7-1": "Unique 60 character ID displayed to the consumer", "8-1": "The saved name of the template displayed to the consumer", "9-1": "Timestamp of when the page was served to the consumer", "10-1": "URL to the screenshot taken for this transaction.", "11-1": "The mobile number of the user", "h-0": "Parameter", "h-1": "Description" }, "cols": 2, "rows": 12 } [/block] These lookup requests can be made up to 72 hours after the transaction. [block:parameters] { "data": { "h-0": "Error", "h-1": "Description", "0-0": "Invalid", "1-0": "Invalid MSISDN", "2-0": "Invalid Shortcode", "3-0": "Invalid Keyword", "4-0": "Invalid Message", "5-0": "Invalid Shortcode", "6-0": "Invalid Pin", "7-0": "Expired", "0-1": "API Key is missing", "1-1": "MSISDN parameter is missing", "2-1": "Shortcode parameter is missing", "3-1": "Keyword is missing, or MSISDN matched but keyword did not match.", "4-1": "No MO message was found", "5-1": "MSISDN matched, but shortcode did not", "6-1": "Pincode did not match", "7-1": "Request is over 72 hours old" }, "cols": 2, "rows": 8 } [/block] [block:api-header] { "type": "basic", "title": "MO PSMS Robust Verification Template Format" } [/block] The following template format overrides all existing Payforit functionality as expected on the usual payforit flow. Pages, once submitted, will still need to undergo the usual approval processes, however this is limited to ImpulsePay’s approval only. To create a button, use the following code: [block:code] { "codes": [ { "code": "<button type=\"psms-mo\" \n data-friendlyname=“my comp”\n data-shortcode=\"89365\"\n data-body=\"#keyword# to win something #UUID#”><div>some html</div>\n</button>", "language": "html" } ] } [/block] Although this uses a button format, it will actually create an HREF tag. [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "Friendlyname", "0-1": "Unique identifier for this button", "1-0": "Shortcode", "1-1": "The shortcode number that the MO should be sent to", "2-0": "Body", "2-1": "SMS body for the message. Use #keyword# as placeholder for where the keyword should go and #UUID# for where the unique entry code goes (which is a shortened version of the PWID). UUID consist for a base36 shortID (5 chars), ‘-‘ and a 5 character salt." }, "cols": 2, "rows": 3 } [/block] The HTML code within the button tag will be encapsulated within the output tag. The keyword should be passed by the merchant via the ServiceURL as ‘KW’. [block:api-header] { "type": "basic", "title": "MO PSMS UUID Lookup" } [/block] A new API has been created to look up the UUID value for a session: [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/checkpwid?smsid=&Key=", "language": "http" } ] } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "SMSID", "0-1": "The SMSID received in the consumers message", "1-0": "Key", "1-1": "The API Key for the account" }, "cols": 2, "rows": 2 } [/block] The following response parameters can be expected in a JSON format: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "PWID", "1-0": "CampaignID", "2-0": "Note", "3-0": "AffiliateID", "4-0": "UserAgent", "5-0": "URLReferer", "6-0": "AccessURL", "7-0": "TemplateID", "8-0": "TemplateName", "9-0": "Logged", "10-0": "ScreenshotURL", "0-1": "A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.", "1-1": "The CampaignID specified for this request", "2-1": "Merchant specific parameters", "3-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "4-1": "The user agent type for which the transaction was processed for", "5-1": "The URL referrer or SMS message text used to access service (when known)", "6-1": "The URL the consumer has used to access the service", "7-1": "Unique 60 character ID displayed to the consumer", "8-1": "The saved name of the template displayed to the consumer", "9-1": "Timestamp of when the page was served to the consumer", "10-1": "URL to the screenshot taken for this transaction." }, "cols": 2, "rows": 11 } [/block] This request can be made up to 72 hours after the transaction. The log is stored with instance access for 6 months then delayed access for 18 months after (for a total period of 2 years).
Merchants are able to use ImpulsePay's robust verification as a third party tool for their PSMS services, which includes a screenshot at the point of purchase and other verification details. [block:api-header] { "type": "basic", "title": "Hybrid PSMS Robust Verification Template Format" } [/block] Merchant should follow the following template format to use the hybrid PSMS verification flow. The button tag must be contained within a form element that has an ID of PFIForm. Once the pin verification is completed, the form will be submitted to allow you to process the users request. The template should use the following code: [block:code] { "codes": [ { "code": "<form method=\"get\" action=\"http://yoursite.com/page\" id=\"PFIForm\">\n <button type=\"psms-hybrid\" \n data-friendlyname=\"my comp\"\n data-shortcode=\"89365\"\n data-msisdnInstruction=\"enter number\"\n data-msisdnInputID=\"abc1\"\n data-msisdnButton=\"click me\"\n data-pinInstruction=\"enter pin\"\n data-pinInputID=“def2”\n data-pinButton=\"click this\"\n data-smsSender=\"89365\" \n data-smsBody=\"#pin# or #keyword#\">\n </button>\n</form>", "language": "html" } ] } [/block] This will create a form object for the MSISDN and Pin entry details which can then be styled and referenced via CSS. During the process, the following javascript functions will also be called: 1. After user enters their MSISDN: - The function hybridMSISDN(ButtonID) will be called, which is used to check the MSISDN is valid. 2. After request to send SMS: - The function hybridMSISDNError(ButtonID, response) will be called, which will provide the reason for any errors during sending. Error responses for this function are as follows: ExceededMaxMSISDN => max 3 attempts have been exceeded MSISDNWait => less than 60 seconds between attempts to send a pin code success => pin was successfully sent 3. After user enters PIN: - hybridPIN(buttonID) will be called, which can be used to validate the pin code 4. After request to check pin: - hybridPinError(ButtonID, response) will be called, which provides any errors during the pincode validation. Error responses for this function are as follows: ExceededMaxPin => max 3 attempts exceeded PinWait => less than 60 seconds during attempts success => pin code is valid failed => pin code is incorrect [block:api-header] { "type": "basic", "title": "Hybrid PSMS Robust Verification Lookup API" } [/block] When the user submits the Hybrid form, the PWID and pin code parameters are passed to the form. The following API can be used to check they are valid: [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/checkhybrid?PWID=&Pincode=", "language": "http" } ] } [/block] Alternatively you can call this API if the user sends an MO message in: [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/checkhybrid?MSISDN=&Keyword=&Shortcode=", "language": "http" } ] } [/block] The following response parameters can be expected in a JSON format: [block:parameters] { "data": { "0-0": "PWID", "1-0": "CampaignID", "2-0": "Note", "3-0": "AffiliateID", "4-0": "UserAgent", "5-0": "URLReferer", "6-0": "AccessURL", "7-0": "TemplateID", "8-0": "TemplateName", "9-0": "Logged", "10-0": "ScreenshotURL", "11-0": "MSISDN", "0-1": "A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.", "2-1": "Merchant specific parameters", "1-1": "The CampaignID specified for this request", "3-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "4-1": "The user agent type for which the transaction was processed for", "5-1": "The URL referrer or SMS message text used to access service (when known)", "6-1": "The URL the consumer has used to access the service", "7-1": "Unique 60 character ID displayed to the consumer", "8-1": "The saved name of the template displayed to the consumer", "9-1": "Timestamp of when the page was served to the consumer", "10-1": "URL to the screenshot taken for this transaction.", "11-1": "The mobile number of the user", "h-0": "Parameter", "h-1": "Description" }, "cols": 2, "rows": 12 } [/block] These lookup requests can be made up to 72 hours after the transaction. [block:parameters] { "data": { "h-0": "Error", "h-1": "Description", "0-0": "Invalid", "1-0": "Invalid MSISDN", "2-0": "Invalid Shortcode", "3-0": "Invalid Keyword", "4-0": "Invalid Message", "5-0": "Invalid Shortcode", "6-0": "Invalid Pin", "7-0": "Expired", "0-1": "API Key is missing", "1-1": "MSISDN parameter is missing", "2-1": "Shortcode parameter is missing", "3-1": "Keyword is missing, or MSISDN matched but keyword did not match.", "4-1": "No MO message was found", "5-1": "MSISDN matched, but shortcode did not", "6-1": "Pincode did not match", "7-1": "Request is over 72 hours old" }, "cols": 2, "rows": 8 } [/block] [block:api-header] { "type": "basic", "title": "MO PSMS Robust Verification Template Format" } [/block] The following template format overrides all existing Payforit functionality as expected on the usual payforit flow. Pages, once submitted, will still need to undergo the usual approval processes, however this is limited to ImpulsePay’s approval only. To create a button, use the following code: [block:code] { "codes": [ { "code": "<button type=\"psms-mo\" \n data-friendlyname=“my comp”\n data-shortcode=\"89365\"\n data-body=\"#keyword# to win something #UUID#”><div>some html</div>\n</button>", "language": "html" } ] } [/block] Although this uses a button format, it will actually create an HREF tag. [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "Friendlyname", "0-1": "Unique identifier for this button", "1-0": "Shortcode", "1-1": "The shortcode number that the MO should be sent to", "2-0": "Body", "2-1": "SMS body for the message. Use #keyword# as placeholder for where the keyword should go and #UUID# for where the unique entry code goes (which is a shortened version of the PWID). UUID consist for a base36 shortID (5 chars), ‘-‘ and a 5 character salt." }, "cols": 2, "rows": 3 } [/block] The HTML code within the button tag will be encapsulated within the output tag. The keyword should be passed by the merchant via the ServiceURL as ‘KW’. [block:api-header] { "type": "basic", "title": "MO PSMS UUID Lookup" } [/block] A new API has been created to look up the UUID value for a session: [block:code] { "codes": [ { "code": "http://bill.impulsepay.com/checkpwid?smsid=&Key=", "language": "http" } ] } [/block] [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "SMSID", "0-1": "The SMSID received in the consumers message", "1-0": "Key", "1-1": "The API Key for the account" }, "cols": 2, "rows": 2 } [/block] The following response parameters can be expected in a JSON format: [block:parameters] { "data": { "h-0": "Parameter", "h-1": "Description", "0-0": "PWID", "1-0": "CampaignID", "2-0": "Note", "3-0": "AffiliateID", "4-0": "UserAgent", "5-0": "URLReferer", "6-0": "AccessURL", "7-0": "TemplateID", "8-0": "TemplateName", "9-0": "Logged", "10-0": "ScreenshotURL", "0-1": "A 75 character unique ID for this transaction. In the event of the notification being retried, this will be persistent across all requests.", "1-1": "The CampaignID specified for this request", "2-1": "Merchant specific parameters", "3-1": "Affiliate tracking info that was requested using the AffID parameter when making the request. The parameters are delimited using a semi-colon.", "4-1": "The user agent type for which the transaction was processed for", "5-1": "The URL referrer or SMS message text used to access service (when known)", "6-1": "The URL the consumer has used to access the service", "7-1": "Unique 60 character ID displayed to the consumer", "8-1": "The saved name of the template displayed to the consumer", "9-1": "Timestamp of when the page was served to the consumer", "10-1": "URL to the screenshot taken for this transaction." }, "cols": 2, "rows": 11 } [/block] This request can be made up to 72 hours after the transaction. The log is stored with instance access for 6 months then delayed access for 18 months after (for a total period of 2 years).