Paylink is a comprehensive, low latency, secure and flexible online hosted payment form. It has been built from the ground up to cater for mobile and responsive design, meaning that your payments can be completed on a desktop, tablet or smartphone catering for IOS, Android or conventional browser environments.
Comprehensive: Paylink caters for the entire payment process including authorisation, payment notifications and validation.
Secure: Paylink 3 uses the latest browser security models to protect merchant and customer data, and is rigorously tested each time a new version is deployed.
Flexible: Paylink is flexible by nature, it is responsive to the viewer's experience and offers a vast array of customisations.
Paylink makes online e-commerce easier to implement by handling the card payment process direct with the cardholder's browser and CityPay's payment processing servers, allowing you to concentrate on your business whilst allowing us to handle the payment process.
CityPay are also a PCI Level 1 accredited service provider, which streamlines your PCI accreditation process by indirectly handling sensitive cardholder data (CHD).
Key Benefits of Using Paylink
- Simplified payment solutions;
- payment processing is handled by our secure web servers adding security and confidence to your shoppers;
- 3D-Secure authentication is available within the application without any difficult MPI integration, allowing for immediate Verified by Visa and MasterCard SecureCode processing;
- customisation may be performed on the secure payment form;
- significantly reduced technical and financial overheads associated with software implementation and PCI compliance;
- reduced time-to-market.
Paylink 3 supports JSON, XML and application/x-www-form-urlencoded data exchange to create token based payment requests and payment notifications.
Token Based Payments
Paylink interacts with the Customer using a Payment Token embedded in a URL. The token is created by your application, calling the Paylink server create process to generate the token. You are then able to provide the generated token to the card holder via multiple methods, including HTTP redirection (GET or POST), a link in a page, email or pdf or a QR Code.
Paylink provides that every Payment Token is subject to an expiry period which, by default, is 30 minutes. The expiry period may be extended to any length of time either through configuration of the Payment Token Request or by management configuration.
Paylink can perform web hooks using a HTTP POST call to the Merchant Application known as a PostBack. If payment is not made by a customer before the relevant Payment Token expires, Paylink 3 performs a PostBack to advise the Merchant Application that the relevant Payment Token and Payment Transaction has expired.
The Paylink 3 user interface has been developed with the following objectives in mind –
User friendly: the user interface has been written with the aim of guiding the user through the payment process logically and with ease.
Compliance with modern browser standards, the user interface is generated using HTML5 and is tested for compatibility with older browsers.
Wide, cross-platform browser support: Paylink has been developed to support Microsoft Internet Explorer version 8 and above, Google Chrome, Mozilla Firefox, the Opera browser and Apple Safari. It has also been developed to support payment on Android and Apple iOS-based devices.
HTML5 Single Page Application: the user interface is designed as a single page HTML5 application which requires the user to download the page only once where all subsequent interactions between the Customer Browser and Paylink are structured using the XMLHttpRequest API ("XHR") to allow a high level of interaction between the Customer and the Paylink Payment Form.
Responsive design: Paylink's style is built upon a cut down version of Twitter Bootstrap. the payment form automatically scales to fit the screen area available to the customer's browser while maintaining breadth of functionality.
Internationalisation: Paylink generates a Payment Form appropriate to the Customer according to the language reported by and the location implied by the HTTP Accept-Language request header received by Paylink 3 from the Customer Browser.
Pragmatic error reporting
By virtue of its staged validation and processing architecture, Paylink generates a list of all validation errors it encounters when processing an incoming request from the Merchant Application before returning any response. Accordingly, the Merchant Application is able to implement comprehensive error management and reporting.
Paylink maintains a record of the changes a Customer makes to the pre-completed Payment Form, and any subsequent changes the Customer makes to their payment details on each attempted payment submission.
3-D Secure is embedded into Paylink, ensuring that the authentication experience for the user is seamless. No further integration is required to run a fully seamless authenticated transaction process, thereby reducing exposure to fraudulent transactions.
To facilitate integration development and testing, Paylink provides a test transaction mode which behaves in accordance with the production payment processing system. See Testing Best Practices for using the test mode.
Paylink offers the ability for a Merchant Application to provide custom fields for data collection through the payment form.
Card Holder Account Support
Paylink supports the storage of card holder account data which stores card holder data, allowing Merchants to process a payment for subsequent charging.
PCI-DSS requires that the card security code should not be stored and we are therefore unable to store this data. Due to this absence, card holder account payment transactions may be subject to higher transaction charges due to the heightened chargeback risk.
Paylink optionally enables Merchants to apply surcharges to Payment Transactions depending on the type of Payment Card the customer intends to use for the transaction. Surcharge functionality includes support for –
- fixed amount surcharges irrespective of the transaction value;
- percentage surcharges which may operate to pass on the cost of credit cards transaction processing; or
- a mixture of fixed amount surcharges and percentage surcharges which may operate to reflect the different transaction processing approaches adopted for credit and debit card transactions.
We have designed Paylink to be simple in delivery but as secure as possible. Paylink 3 complies with PCI-DSS requirements by following the recommendations of the Open Web Application Security Project ("OWASP") top 10 vulnerabilities as follows –
Injection: the Paylink application is protected from any injection flaws by ensuring that all data is parameterised and input validation is performed before any data is handled by the application.
Broken Authentication and Session Management: Paylink uses the URL as a construct of a session and does not require a session cookie to maintain state. The scope at which this URL is available is configurable such that a payment may be locked to a browser or IP address. The unique identifier in the URL is a 64 bit randomised string that is guaranteed to be unique per merchant.
Cross Site Scripting: Paylink 3 is protected against cross-site scripting ("XSS") attack vectors through a number of mechanisms. All input data is validated, sanitised and encoded before being rendered within the body of the page. We also enable a Content Security Policy ("CSP") for the Paylink application which ensures that the application is only allowed to load page resources from an acceptable list of directives.
Insecure Direct Object References: No references are used in communication between the Merchant Application and Paylink, or the Customer Browser and Paylink 3 that map directly to internal objects with the exception of the Payment Token used for Payment Transaction session management.
Security Misconfiguration: Paylink is deployed in compliance with CityPay's internal security policies that provide for structured security analysis and security hardening of servers based on their potential exposure. CityPay's internal security policies are regularly updated to be abreast of latest security trends and all of our servers are regularly patched and vulnerability tested.
Sensitive Data Exposure: Card holder data is encrypted using HTTPS with validated SSL certificates. Additionally, HTML forms generated are transmitted with the Cache-Control HTTP header set to prevent caching on the Customer Browser, or by any intermediate proxy. The HTML form element is prevented from remembering the data entered by disabling autocomplete. Sensitive data such as the primary account number ("PAN") are encrypted using an asymmetric encryption algorithm immediately following input validation on the server. Throughout its operations, CityPay uses industry standard strong encryption algorithms (AES256) and has adopted key management and rotation process to maintain security.
Missing Function Level Access Control: Every Paylink Payment Token Request is subject to authentication and access control before a Payment Token is generated. Paylink does not have any hidden functions accessed without authentication, or outside the context of an established Payment Transaction session.
Cross Site Request Forgery: Paylink creates a CSRF token in the form of a session based cookie when the Payment Token URL is first accessed. This cookie is used to effectively bind the Payment Token to the relevant Customer Browser session to protect the Payment Transaction against cross-site request forgery ("CSRF") attacks.
Using components with Known Vulnerabilities: any dependencies are subject to scrutiny and are validated for use as a dependency through acceptable use policies. CityPay only uses industry validated components and maintains a vulnerability programme that checks for vulnerabilities against these components.
Unvalidated Redirects and Forwards: The payment token follows an undisclosed, internal algorithm which allows us to validate any Payment Token before it arrives to us. As the token is generated by a server side call, the merchant is able to trust the URL before forwarding the user for payment.
Web browser support
Specifically, we support the latest versions of the following browsers and platforms. On Windows, we have limited support Internet Explorer 8-10 and recommend IE 11 or Edge.