Hosted Field

The MultiPay Hosted Field solution allows you to submit card payment authorisation requests from your website without the complexity of becoming PCI DSS complaint.

The MultiPay Hosted Field solution renders the sensitive Credit/Debit Card Number input field into your website using an iframe that is hosted by PayPoint in our PCI DSS compliant zone.

The cardholder simply completes the Card Number (PAN) input field on our server, we then encrypt the cardholder’s PAN and generate a Token which is then returned to the customer's browser. The Hosted Field solution provides a JavaScript Callback to receive the Card Token along with the Card’s Scheme and Type. The hosted Card Number (PAN) input field can also be easily customised to fit into your payment page design.

To add the required Hosted Field to your website please complete the following steps:

1: Creating your HTML page

To start using the Hosted Field, you need to create a basic HTML Payment Page Form which collects all the cardholder details needed to complete a payment. To add the Hosted Field, you need to define a <div> container in place of the <input> element that would normally comprise of your Card Number input field.

For the Hosted Field to be render correctly as an Iframe the <div> container must have an id of "card_number".

<form> 
 <div class="form-group"> 
  <label for="card_number">Card Number</label> 
  <div class="hosted-field" id="card_number"></div> 
 </div> 
 <div class="form-group"> 
  <label for="card_cvv">CVV</label> 
  <div class="hosted-field"><input type="text" name="CVV" value="" id="card_cvv"/></div> 
 </div> 
 <div class="form-group"> 
  <label for="cardholder_name">CardHolder Name</label> 
  <div class="hosted-field"><input type="text" name="NameOnCard" value="" id="cardholder_name"/></div> 
 </div> 
 <div class="form-group"> 
  <label for="card_expiry">Expiry Date</label> 
 <div class="hosted-field"> 
  <input type="text" name="ExpiryDate" value="" id="card_expiry"/></div> 
 </div> 
 <div class="form-group"> 
  <input type="submit" id="paymentButton" value="Make Payment"/> 
 </div> 
</form>

BACK TO TOP ⇧

2: Adding the Hosted Field JS URL

For the Hosted Field to function, you will need to include the URL of the Hosted Field JavaScript into the <head> of your HTML Payment Page. You must also include your API Subscription Key as part of the URL allowing the authentication of its use.

<script src="https://multipay-sandbox.azure-api.net/hostedfield/v1/GetHostedFieldScript?subscription-key={API_SUBSCRIPTION_KEY}" type="text/javascript"></script>

3: Invoking the JavaScript

To invoke the Hosted Field solution, you need to include the following script which will render the Hosted Field Iframe in the position of the correctly labelled <div> container, stylise the Iframe's content and create a callback for the returned Card Token.

We suggest that you invoke the JavaScript on page load to give your customers a seamless experience.
Note: The placeHolder value must match the <div> container id 'card_number'.

<script> 
 function callbackFunction(cardType, cardToken) 
  { 
   document.getElementById("cardTokenValue").value = cardToken; 
   document.getElementById("cardTypeValue").value = cardType; 
  } 
 function doOnHostedFieldErrorFunction(status, statusText, errorMessage, errorCode) 
  { 
   console.log(status, statusText, errorMessage, errorCode); //status: '0', 
   statusText: 'None', 
   errorMessage: 'Credit card number is invalid', 
   errorCode: '999' 
  } 
window.onload = function () 
 { 
  var _ = new PayPointHostedFields.HostedFields(
 { 
  field: 
   { 
    placeHolder: 'card_number', 
    style: 
     { 
      'width': '220px', 
      'color': '#606060', 
      'border': '1px solid #606060', 
      'background': '#fff', 
     }, 
    errorStyle: 
     { 
      'border': '1px solid #ff0000', 
     }
    }, 
  callback: callbackFunction, doOnHostedFieldError: doOnHostedFieldErrorFunction 
  }); 
 } 
</script>

BACK TO TOP ⇧

4: Customising the style of the Iframe's content

To add an inline style to the Hosted Field so that it looks the same as your payment page design, simply add valid CSS to the JavaScript as shown below:

field: 
 { 
  placeHolder: 'card_number', 
  style: 
   { 
    'width': '220px', 
    'color': '#606060', 
    'border': '1px solid #606060', 
    'background': '#fff', 
   }, 
  errorStyle: 
   { 
    'border': '1px solid #ff0000', 
   }
  },

BACK TO TOP ⇧

5: Submitting the Guest Payment

To complete a Guest Payment request your website's payment page needs to collect the Amount, Account Type, Customers Details & Card Details including the CVV, Expiry Date and then combine them with the returned Card Token & Card Type before sending the request for authorisation using the Guest Payment API.

6: Your Website & Payment Scheme Compliance

As a Client integrating into the PayPoint Payment Platform you are required to comply with the following various Card Schemes rules and Website/APP requirements:

TERMS AND CONDITIONS OF SALE

Clients should at all times clearly display on their payment page the terms and conditions of sale. In addition, the Client should at all times display in a prominent position on their payment page a complete and accurate description of the approved product(s) offered for sale or supplied by the Client and the nature of the commitment that the cardholder is assuming.

Client's payment page should contain clear details and information about customer service, its contact details (including legal name, trading name, legal address, business address, email, phone and fax), currencies accepted, and the country of its domicile and registration (if applicable) and its refund policy. Clients should also comply with all requirements and guidelines in respect of Internet payments issued by the Acquirer/Processor or any Card Scheme together with all legal and regulatory requirements that apply from time to time.

Clients should clearly inform the cardholder that they are committing to payment before they select to continue with any action that should result in a payment to the Client. Clients should afford the cardholder an unambiguous option to cancel the payment at this juncture.

Clients must clearly inform the cardholder what information they are collecting and what they intend to use the information for with a Privacy Policy.

ACCEPTANCE LOGOS

Client Website/APP must display the logos of the payment methods that can be accepted at the point the customer enters their payment details.

To add Visa Card Logos, please visit: https://usa.visa.com/run-your-business/accept-visa-payments/posguidelines.html

To add MasterCard Card Logos, please visit: https://brand.mastercard.com/brandcenter/mastercard-brand-mark/downloads.html

The "Powered by PayPoint" logo must also be displayed on your website ideally on the same page as the card logos. This reassures your customers that their payments will be processed by a recognised secure payments provider. The "Powered by PayPoint" logo must also be hyperlinked to https://www.paypoint.com.

The "Payments Powered by PayPoint" logo can be downloaded at: https://multipay-sandbox.developer.azure-api.net/content/poweredby.png

DISCRIMINATORY SURCHARGES

Clients should not directly or indirectly require any cardholder to pay a surcharge, to pay any part of the fees, whether through any increase in price or otherwise, or to pay any separate charge in connection with the transaction in which a card is used. A surcharge is any fee, charged directly or indirectly, deemed by the Card Schemes to be associated with the use of a card that is not charged if another payment method is used.

Clients may not engage in acceptance practices that discriminate against, or discourage the use of a specific card brand in favour of any other card brand or payment method that is also accepted.

REFUNDS

The Client should only process Refunds where there is a corresponding sale and then only up to the value of that sale and no more. Refunds should only be made to the card upon which the original sale was debited and not to any other card.

STORED CREDENTIALS & RECURRING/INSTALMENT PAYMENTS

A stored credential is information (including, but not limited to, an account number or payment token) that is stored by the client to be used for the following type of transactions:

Recurring – A transaction in a series of transactions processed for the purchase of goods or services provided at regular or fixed intervals.

Instalment – A transaction in a series of transactions processed over a set period and number of payments for a single purchase of goods or services.

Unscheduled credential on File (UCOF) - A transaction using a stored credential for a fixed or variable amount which is not part of a scheduled or regular agreement but where the cardholder has provided consent for the merchant to initiate one or more future transactions.

Cardholder initiated credential on file (CIT COF) - A transaction using a stored credential for a fixed or variable amount which is not part of a scheduled or regular agreement but where the cardholder themselves initiates the payment.

When capturing a Stored Credential for the first time using the Account Verification API, the client must establish a schedule agreement with the Cardholder that contains all the following:

A truncated version of the Stored Credential (for example: last 4 digits of the Account Number), as it may be updated from time to time
How the Cardholder will be notified of any changes to the schedule agreement
How the Stored Credential will be used
The expiration date of the schedule agreement, if applicable

Clients taking a recurring, instalment or Unscheduled credential on file payments must obtain the cardholder's express consent and inform the cardholder the exact details of the schedule agreement including:

The Transaction amount and currency (including all associated taxes and charges) or a description of how the Transaction amount will be determined
Whether the amount is fixed or variable
The Schedules date(s) of the Recurring / Instalment Payment
Whether the Schedules date(s) are fixed or variable
Cancellation and refund policies
For Recurring Transactions, the fixed dates or intervals on which the Transactions will be processed.
For Instalment Transactions, the total purchase price and the terms of future payments, including the dates, amounts, and currency
For Unscheduled Credential-on-File Transactions, the event that will prompt the Transaction (for example: if the Cardholder's balance falls below a certain amount)

Any changes to a cardholder’s Payment Schedule Agreement must also be communicated at least seven working days prior to the next payment being taken. You must communicate to cardholder in any of the following situations:

More than six months have elapsed since the last payment
A trial period, introductory offer or promotional activity has expired

There are changes to the Recurring/Instalment Agreement: - any change to the amount of the Payment and/or - any change to the date of the Payment.

BACK TO TOP ⇧