PFI Ajax allows a merchant to provide detailed interactive content to users via the PFI proxy, so that PFI can be used for handset identification and billing. As a rough overview, a typical response might work like this:
-
The user hits the merchant URL, which is pointed to the PFI Ajax server
-
The PFI Ajax server looks up the request URL to determine the merchant, pulls content from the merchant server, and renders it to the user’s browser
-
The user interacts with merchant content. Each click fires an AJAX request to the PFI Ajax server, which is sent via server-to-server connection to the merchant server. Responses are interpreted by the PFI Ajax server and sent in a JSON response to the Ajax request on the user’s browser
-
When a PFI-enabled button appears, the application enters Injects the PFI payment content into the merchant site, where the PFI header is displayed and all mandatory PFI buttons are rendered
-
As the user progresses through the PFI flow, calls are made to the merchant server. Scripts can be run on the user’s browser to improve the user journey and improve conversions
- When the PFI flow completes, the user is redirected to the content URL, which may be another area of the PFI Ajax-enabled site, or a completely different site.
The PFI Ajax server ( pfiajax.imimobile.net ) is the main proxy application hosted and maintained by IMI Mobile. In order to use the application, two separate new domain names will be required:
| Value | Description |
|---|---|
| Requested Site | Should be domain of merchant’s choice CNAMED to pfiajax.imimobile.net. This is the URL the users will navigate to |
| Content Host | This hosts the merchant DOM |
Examples
Step 1:
Cnamed URL is requested by a user and a standard merchant site is loaded containing Payment purchase buttons or JS script call to initiate payment pages
Step 2:
Upon activating payment pages, appropriate headers and purchase flow is loaded into div element of merchant’s choice.
Step 3:
On confirm page the user is prompted to send a SMS into a specific SC using a random code for identification
Step 4:
PFI will pick up on the code send in, identify there user and attempt billing. Confirmation when complete can be shown (optional) or directed to success URL
MT Flow Example
Step 1:
Cnamed URL is requested by a user and a standard merchant site is loaded containing Payment purchase buttons or JS script call to initiate payment pages
Step 2: User is prompted to enter there MSISDN for which they will receive the below code to verify their identity. This code is entered at step 3.
Example:
FreeMsg: Use code ABBOT to verify your purchase of £0.25
Step 3:
User enters the provided code from the MT SMS
Step 4:
Verification and billing takes place. User is presented to the payment confirmation or success URL of the merchant (optional)
HYBRID Flow Example
Step 1:
Cnamed URL is requested by a user and a standard merchant site is loaded containing Payment purchase buttons or JS script call to initiate payment pages
Step 2:
User is prompted to enter there MSISDN for which they will receive the below SMS MT which will contain a URL link to confirm and complete the payment
Step 3:
The user will receive a MT SMS link like the below:
Example:
FreeMsg: Please click this link http://octoray/PfiHome/Confirm?token=63arHcMUI33L to confirm acceptance and this will verify your mobile number if you wish to proceed with your purchase of octoray Video for £0.25 from octoray. Help? 0800500600
Upon Clicking the link, the user is confirming the acceptable of the charge and is directed back to the Merchant page.
Step 4:
Once User has landed back on the merchant site, the user is billed and directed to a payment confirmation page or the merchant’s content page.
WIFI Shield Flow Example
Wi-Fi flow allows access as per standard flow of a data user. However should the user arrive from WIFI. The merchant can chose to allow IMI to present a prepopulated Landing shield as per above example, which upon clicking or after 5 seconds, will direct the user to a in phone SMS app, with a prepopulated Shortcode and Keyword to send in.
Upon doing so the user will be verified and provided a bounce back MT with a link to grant access to the merchant site, as if the user was on data.
(Optional) the merchant can host the Wi-Fi shield themselves if they want control of the styling.
Wi-Fi Vs 4g Access
If a user arrives on data, on any flow, they will progress through a merchants site seamlessly by simply completing the double opt in payment flow. The user is only required to interact with the 2 main pages and simple buttons attached to them. This is the quickest and smoothest experience a user on a merchant site can experience.
WIFI users (depending on flow in use) do have the additional step of having to verify there MSISDN and network. As above options there are multiple ways to achieve this dependant on merchant choice