Overview of the PaymentService Structure
Newland PaymentServices is an independent payment module designed to enable customers to quickly complete payment application development. It contains a series of actions that provide the core functionalities based on EMV chip and PIN technology for third-party applications. These functionalities include the following Card Services:
Purchase Service (attended and unattended). This is the basic Card Service on the terminal and performs a transaction that generates all necessary data for authorisation, clearing, and settlement required to pay for the purchase of goods, services, etc. The following options are also covered:
Instalment Payment (only attended). This is a service where the cardholder authorises a card acceptor to split the payment of a single purchase of goods or services (with or without charges) in a finite number of periodic transactions, with a specified end date. The payment schedule and conditions are agreed between the merchant and cardholder.
Recurring Payment (attended and unattended). This is a service where a cardholder authorises a card acceptor to charge their account on a recurring basis without a specified end date.
Refund Service (only attended). This is a service which allows the card acceptor to reimburse the cardholder partially or totally, e.g. when the cardholder returns goods to a merchant. Refund is linked to a previous transaction to which it may refer.
Original Credit Service (only attended). This is a service which allows the card acceptor to perform a credit to a cardholder's account. An Original Credit is not linked to a previous transaction.
Cancellation Service (only attended). This is a Service which occurs when a previously performed transaction is cancelled by the attendant. This may be restricted to the last transaction processed at the terminal or may be extended to any transaction not yet cleared to the issuer. The Cancellation Service may also be known as "Manual Reversal".
Pre-Authorisation Services (attended and unattended). These are Services used mainly but not only in the hotel and car rental businesses to fulfil the business requirements related to the fact that services are rendered in several steps. The first step is Pre-Authorisation which is used to secure an amount for a specific period of time. During the authorisation, the amount is only secured since neither the final amount nor the final date and time of the actual payment are known. Subsequent steps of this Service may be Update Pre-Authorisation and Payment Completion.
No-Show (only attended). This is a service which allows the card acceptor to charge the cardholder's account if a cardholder fails to cancel or use a reservation for car hire or room rental.
Card Validity Check (attended and unattended). This is a Service which allows the validity of the card to be checked. This Service has no financial impact on the card account. This Service can also be referred to as a Card Account Status Check.
Cash Advance (only attended). This is a Service which allows the cardholder to withdraw cash at a merchant POS terminal or a bank counter.
Quasi Cash (attended and unattended). This is a service which allows the cardholder to obtain items which are representative of actual cash and directly convertible to cash. Examples include gaming chips, travellers cheques.
Deferred Payment (attended and unattended). This is a Service which, together with the Deferred Payment Completion, enables the card acceptor to perform an authorisation for a temporary amount and a completion for the final amount within a limited time frame.
Lightweight Development Easy and fast integration of an acquiring application, even people without any payment industry experience can quickly complete the development of an acquiring application. You don't need to worry about complex EMV standards or how to organize a payment transaction. You can simply call our payment card service, and the remaining PaymentService will handle it for you. It meets regulatory standards and market requirements.
Quick L3 Authentication Using PaymentService means that you are following the EMV standard, meeting the L3 authentication requirements of the card organization, and can quickly complete L3 authentication and deploy it. At the same time, PaymentService, as an independent payment module, encapsulates the transaction service process processing, terminal and card interaction processing. Adjustments to some UI interfaces of the application will not affect the transaction process of PaymentService, so there is no need to re-authenticate L3. Using PaymentService can ensure the consistency of L3 authentication and effectively reduce the re-authentication of L3.
Flexible Transaction Process Rich global market specification support and configuration management can support market demands in different regions of the world or business rules between different merchants without the need for redevelopment. We have rich configuration parameters, and configuring different parameters can complete the adjustment of transaction processes. We provide customers with XML configuration files, and different XML configurations can execute different transaction business processes. Of course, you can also manage these configurations through TMS or other methods.
Custom UI Support developers to draw their own UI. PaymentService does not bind UI, and all UI can be drawn by developers themselves. Besides, based on rich global market experience, we provide you with standardized, user-friendly prompts guidelines. These guidelines are transmitted through the APIs, and you only need to organize the UI display in these APIs.
Host Processing Interface Support access to any host processor, PaymentService is also host protocol agnostic and abstracts the API for accessing the host processor, provides the transaction data needed to access the host, and developers can implement interaction protocols with the host in these APIs, mapping to any host processor.
Rich Market Functions Support rich market functions, DCC, Multi-Acquirer, Multi-Merchant, etc.
Flexible Integration Option 1: PaymentService can be offered as a separate compiled scheme certified EMV library, that can be built into your own 3rd party payment application. Option 2: PaymentService can be offered as a scheme certified EMV standalone application, allowing any 3rd party app developers to develop their own payment app and just call PaymentService to request a payment approval.
Excellent Transaction Performance Using PaymentService (from finding the card to printing the receipt) for a typical contact transaction can be completed within 2 seconds, and a typical contactless transaction can be completed within 400ms (excluding waiting time for user operation).
Supports Multiple Platforms Our core code is written in C language, which allows us to reuse the same code on different platforms to ensure consistent functionality across platforms. Currently, we have Android version, JS version, and C version. Besides, we can quickly complete the porting and development of another new platform.
Global Certification Standards Passed L3 certification tests in multiple countries and regions around the world, including Spain, France, United Kingdom, Germany, Russia, US, Canada, Mexico, Indonesia, Japan, Australia, India, Brazil, Chile, etc.
Overview of Application developed based on PaymentService
When we use PaymentService to create an application, there are some modules that the application needs to be responsible for completing, including
SCAP (Sale system, Cardholder and Attendant Protocol) This module is responsible for handling the interface to the cardholder and/or attendant and/or the sale system. During a transaction, PaymentService needs to communicate with the cardholder and/or attendant and/or with the sale system, e.g. in order to request or to provide information on status or data of PaymentService or to request the printing of receipts. We assume that SCAP provides the following functionality:
SCAP may support functionality such as administrative and maintenance functionality e.g. request of the status of a transaction, SCAP security management.
HAP (Host Acquirer Protocol) HAP is responsible for handling the acquirer protocol and the storing of transaction data. We assume that HAP provides the following functionality:
HAP must support functionality such as administrative and maintenance functionality e.g. reconciliation, diagnostics, online key management and retrieval of data from a corrupted batch file of a defective terminal.
PaymentService provides two integrated options for applications, one is a library (AAR package), and the other is a standalone application (we also provide an AAR library to call PaymentService APIs).
In this way, PaymentService can be directly integrated into the customer application, and PaymentService is always updated synchronously with the customer application.
In this way, PaymentService is a completely independent payment service, and application updates do not affect PaymentService, which can better demonstrate the consistency of L3 certification and effectively reduce L3 re-certification.
We release PaymentService through SDK Manager.
After you download and install the SDK package, you can find PaymentService in the following path:
AAR & APK: \NPT_SDK\Android\api\PaymentService.
Documents: \NPT_SDK\Android\doc\PaymentService.
Demo: \NPT_SDK\Android\demos\PaymentService_Demo.
