CHALLENGES & SOLUTIONS

Size: px

Start display at page:

Download "CHALLENGES & SOLUTIONS"

Diane Owen
5 years ago
Views:

1 FRONT-END INTEGRATION FOR A TOP PSP: CHALLENGES & SOLUTIONS WHITEPAPER

2 FRONT-END INTEGRATION FOR A TOP PSP: CHALLENGES & SOLUTIONS A large-scale Payment Service Provider with years of experience was up for a major payment interface and API re-design to leapfrog the competition. This whitepaper describes the challenges faced and the solutions that ISAAC designed and developed for Ingenico epayments Ingenico epayments, formerly GlobalCollect, is a 100% subsidiary of Ingenico Group, global leader in seamless payments. Headquartered in Amsterdam and Brussels, Ingenico epayments has regional offices in North America, Asia Pacific, South America and the EU. ISAAC is a leading e-business enabler. Based in Eindhoven, ISAAC focusses on solutions and services in the B2B e-commerce and transactional industries in Europe. ISAAC has a dedicated and highly skilled team of interaction, integration and e-business specialists that work together to always support customers, based on the company motto: JOINT EFFORT! Following an extensive section process where software houses were rated on knowledge and experience of interaction design, mobile, API design, security, experience in the payments arena, developer-focus and technology stack. Ingenico selected ISAAC as primary firm to run the transformation project of all front-facing aspects of their infrastructure. A joint project team of specialists, architects and developers was formed in Hoofddorp and Eindhoven and an iterative design and- prototype process was started. After almost a year of re-thinking online payments in general, testing proof-of-concepts, test runs, sandboxing and user testing with a number of selected merchants, the new platform was ready for prime-time in early 2016.

3 AN INTRODUCTION TO... INGENICO EPAYMENTS AND THE PROJECT Ingenico epayments, part of the Ingenico group, is a leading worldwide Payment Service Provider (PSP) offering hundreds of payment methods in most of the world. Ingenico offers these payment services to large-scale merchants who want to process cards and more local alternative payments (like the Dutch ideal) for a global customer base. In addition to payment services, Ingenico also offers fraud screening through its API. Although the proposition of Ingenico epayments was still very competitive, the hosted payment pages and integration APIs were somewhat out-of-date. The hosted payment pages were not fully mobile friendly, hard to customize and (conversion-)test by merchants, and didn t support seamless back-button navigation. The APIs for server-to-server e-commerce integration were XML-based but not on-par with the latest modern REST web standards, and after many years of acquiring more and more functionalities, up for a full re-design. For e-commerce merchants with a native app presence on ios and Android, no inapp payment model was available. In addition to these mainly functionality based aspects, a desire for a new focus on developers was voiced based on an overall web technology and process paradigm shift. Ease of boarding as a merchant, the ability to be agile and over-all developerfriendliness of the APIs and documentation were deemed key to play seriously in the online payments world. Together, the full improvement plan was labelled as Ingenico Connect

4 ARCHITECTURE & COMPONENTS The full solution defined consists of a number of core components. Architecture-wise, the concept of micro services was used, defining clear (and intentionally limited) responsibilities per layer and component, and orchestrating the coordination and data flow between them. Some new components and concepts in the front-facing offerings of Ingenico epayments are: All the architecture components cooperate via standard service calls and handle data integration via a data grid implementation, providing scaling, fail-over and resilience. A new, clean REST API with a new security model, no longer based on IP whitelisting A reusable authentication service handling security and authentication issues A client-to-server security model and API for native, in-app payments MyCheckout hosted payment pages template engine and server-side component MyCheckout hosted payment pages in-browser editor for PCI-DSS level A payment processing Software Development Kits (SDKs) wrapping the feature-rich Server-to-Server REST API for Java and PHP e-commerce servers SDKs wrapping and implementing the Client-so-Server REST API and security model for native in-app payments on ios and Android A JavaScript SDK for merchants who want total freedom on the look & feel of their payment pages, while maintaining at least PCI-DSS A-EP certification Example apps to provide easy carbon-copy agile development approaches for merchant app developers A secure configuration center where merchants can access and edit their payment page setup, A/B-tests and security elements like API keys. A public developer hub with information on all API operations, payment page usage and payment product characteristics and best practices.

5 CHALLENGES & SOLUTIONS... PCI-DSS LEVEL A PAYMENT PAGES The payment card industry (PCI) is strictly governed by the PCI-DSS standard on payment card data security. In early 2014, PCI was updated to version 3, an important milestone for merchants and payment service providers. PCI-DSS 3.0 states on PCI Level A (the level where the merchant is bothered with the least security restrictions possible): During the payment process, the consumer s browser is redirected to a checkout/payment page (URL or iframe) that is entirely controlled by a PCI-compliant 3rd party service provider This poses a challenge, as entirely controlled means no CSS or Script can be loaded from the merchant, severely limiting the options a merchant has to apply his own style and perform A/B-testing, with reduced conversion optimization options as a result. Many PSPs use a model where merchant CSS files are manually reviewed by them before they are activated; for Ingenico and their renewed focus on supporting continuous merchant conversion optimization, we could not accept this. A solution was found by keeping all JavaScript and CSS assets in the Ingenico Connect domain, but offering a sophisticated API for A/B testing that integrates with any multi-variant testing framework. More interesting though is the online style / CSS editor, the so called Payment Page Editor (PPE). Using a browser based, Adobe-style editing framework that will feel familiar to marketeers and conversion specialists, the PPE provides direct access to styles, fonts, colors and templates, while doing this on a basis of responsive and already highly optimized presets. Merchants can test multiple variants, tweak while running in production and direct traffic to any optimization variant they can think of. All of this in a fully PCI-DSS Level A compliant environment. Testing of newly styled payment pages is supported by in-browser tablet and smartphone formfactor simulators, but we also offer easy omni-channel testing access by supplying scannable QR codes to load and distribute a test variant on your phone and sharing it with others before making a production decision.

6 CHALLENGES & SOLUTIONS... THE CONTINUOUS IMPROVEMENT CYCLE FOR PAYMENT PAGES VIA MYCHECKOUT With the Payment Page Editor, Ingenico has a unique tool to support even the most demanding merchants that can t be bothered with PCI-DSS levels A-EAP and D. Multiple variants Setup new MyCheckout payment page variants Responsive UAT test on mobile devices Ingenico Connect Server Test and communicate within merchant organisation Run variants in shop Test Framework 50% 60% Evaluate conversion results, theorize and make assumptions

7 CHALLENGES & SOLUTIONS... CLEAN NEW REST API ON LARGE OPTION SET Ingenico epayments has a rich offering of card and alternative payment products from around the globe. Their core systems support Design Tools Backend Systems Hierarchy tokenization, fraud screening, lookup services and financial mechanisms like payouts, currency conversions and refunds. It is a challenge to present all of this functional richness in a clean, not overwhelming fashion to merchants who are new in this area. The landscape is a lot more extensive than that of new PSPs that recently stormed the marked with a limited payment product portfolio. To present the rich service set, ISAAC designed and implemented a completely new, structured REST API that is documented using RAML. In this APIstructure, special care was taken to use the correct nouns that clearly map to concepts and hierarchy. The structure of this API cascades on to a number of other, supporting components, like the full API reference in the developer portal, the server SDKs (Java and PHP) and client SDKs (Android, ios and JavaScript). This synchronization of the interfaces of a number of components is an error-prone process. To reduce this risk, software and code generation tooling was deployed. Using a formal object hierarchy and reusable scripting, the REST API, the API reference and the SDKs are always automatically in synch, making sure merchants have a seamless experience when integrating, testing and running against the Ingenico Connectt REST API. B+ + JSon RAML APi RAML JSon Developers Portal SDKs

8 CHALLENGES & SOLUTIONS... PERFORMANCE AND FAIL-OVER Ingenico epayments processes payments for some of the world s largest and most demanding merchants. A service provider like that has to be performant and always-on. At peak, over three hundred payments per second are processed from a number of data centers. This raises challenges around data synchronization, session replication and fail-over behavior. DATA PROPAGATION, WORLDWIDE IN A SECURE GRID SERVER SIDE PERFORMANCE The new front-facing components have to participate fully in this infrastructure fabric of performance and reliability. To achieve super responsiveness, heavy caching is performed, while component interaction mostly uses a Data Grid solution for storing, replicating and retrieval of data. Nodes of any type (running the various micro services) can be configured to participate in the grid and thus share data with other components of the same type and layer. In real-time, nodes can be added or removed from the grid to change performance characteristics and infra-resilience. The grid can also take care of data propagation to other data centers. To make maximum use of the scalability a data grid offers, most server-side components have been designed from the ground up to be fully stateless, except for state that they store in and retrieve from the grid. Component orchestration is achieved on the infrastructure layer.

9 CHALLENGES & SOLUTIONS... PAYMENT PAGE PERFORMANCE Performance is more than just server-side speed of course. In a payment process, especially in a mobile-first world, speed of content delivery is just as key. The payment pages in Ingenico Connect MyCheckout have been designed from the ground up to provide optimal speed of delivery and rendering. To achieve this, we used a combination of optimization methods. The metadata-rich HTML with this is editable -hooks for the web-based MyCheckout editor is filtered to serve-out just that that what is needed to display the pages. All the rest is kept server- and editor-side only. All generic and variant-specific CSS is auto-combined into one streamlined CSS file that is served out with the page. This means, that merchants do not pay a price in speed for customizing their payment pages again and again, while tweaking for optimal conversion. JavaScript is minified, combined and always non-blocking. Even with JavaScript disabled, the Payment Pages are still fully functional, and gracefully degrade to a level that will work on the rendering device. A CDN or Content Delivery Network micro service has been integrated from the start to make sure that even in the most demanding circumstances, static content is available immediately. The payment page editor optimizes images in real time for the required resolution and makes them available to the CDN. Conversion performance on payment pages is also greatly helped by correct and understandable exception process handling; payment products will sometimes fail and customers will press the backbutton when you least expect it. The frontfacing components of the new Ingenico Connect landscape work together to handle this in an optimal way, always aiming to provide the customer with options to continue, and not lose them along the way to a successful payment conversion for the merchant.

10 CHALLENGES & SOLUTIONS... MOBILE FEATURES The new platform has been designed with mobile as a first class citizen. The new client-to-server API that was introduced as part of the project provides a security model that works with native apps and conversionboosting in-app payments. As part of the platform roll-out, we designed SDKs for Android and ios, that app-developers can use to handle the complexity of crypto, hashing and validating payment input. These SDK components are open source, extendable and based around best practices common on the host platform. An example implementation for the key mobile platforms takes merchant development teams by the hand to lead them through the process of integrating payments in their apps. Merchants get all the power of the full native experience without the burden of a lengthy PCI-DSS Level D assessment; the SDK model is compatible with the requirements of PCI- DSS Level A-EP. For merchants who did not develop their own e-commerce apps, the responsive MyCheckout pages offer an even easier PCI Level A solution. These pages offer the option to render shopping cart data, can be styled to fit exactly with the merchant brand and are optimized for delivery over potentially slow mobile data networks. The mobile solutions, both for native and web technology, are available for many locales. With translations and display optimizations for locales as different as Arabic and Chinese, Greek and Hebrew, all merchant customers can be served with the screens that mean most to them, with the payment product they love on the device they trust most: their own smart phone. WANT TO KNOW MORE? Have a look at developer.globalcollect.com for the Developer Hub where a lot of information on the new environment and a free sandbox account is available.

Luckily, our enterprise had most of the back-end (services, middleware, business logic) already.

Luckily, our enterprise had most of the back-end (services, middleware, business logic) already. 2 3 4 The point here is that for real business applications, there is a connected back-end for services. The mobile part of the app is just a presentation layer that is unique for the mobile environment.