New Payment Exchange Introduction · 2015. 5. 25. · In Commercial Confidence 26-May-15 Page 3...

An introduction

26-May-15 In Commercial Confidence

Payment Exchange


Overview

Functionality

Components

Deployment

Topics


Kendra Payment Exchange (KPx) is an IT software component to enable improved online interactions of the existing billing & charging systems of a telecommunications operator with its collection mechanisms.

The system allows finance and business management personnel to have real-time views of the payments position, enabling better decision-making and actions.

Introduction

Postpaid Payments

Autobilling

Bill Presentment

Prepaid Reloads

E-Wallet Reloads

Charges

Pay

me

nt

Exch

ange

Credit Card

PayPal

Bank Account

Prepaid IN

E-Wallet

Postpaid Billing

Financial Mgmt System


The Kendra Payment Exchange (KPx) enhances the existing Business Support System infrastructure.

It is agnostic to the individual customer accounts, i.e. it does not maintain state of a company’s subscribers. Instead it relies on the existing ESB or BSS to retrieve the information that is necessary for processing of the transactions.

It does not collect monies/payments, but recognises payments when they are made; tracks and reconciles the collections with the amounts entering the financial management systems.

It creates merchant wallets for the distribution network parties and enables speedy recognition of monies due to them. It provides efficient cost-effective means to the distributors to support the consumers.

Introduction


Post-paid: payments made through the connected agents are recognized immediately thereby reducing service barring cases leading to better customer experiences

Post-paid: automated reconciliation of the payments received from the connected agents

Connected agents: o immediate recognition of business done through daily credit

of commissions o dealers have real-time knowledge of itemized deposit

drawdown o better cash-flow for the dealers leading to better goodwill

Allow credit cards for online payments

Allows easy introduction of digital alternatives, e.g. the use of soft-pin/pin-less top-ups

Allow easy addition of new dealers/agents into the network and expansion into M-commerce.

Business Benefits


Real-time information for better decision-making and actions

Online approvals and automated reconciliations will shorten processes and reduce errors

Continuous improvement and drama-free upgrades: Our experience is that by implementing new functionalities in smaller parcels but higher frequency, the new releases are implemented smoothly, without inconvenience to the business, truly realizing a faster time-to-market.

Operational benefits

The sustained success and effectiveness of an IT system is very dependent on how the system stays relevant to the users’ business and work-process needs.


Kendra Solutions uses an agile delivery approach:

Focus on the business needs.

Install and deploy first functionality fast, typically within 2 months.

Deliver additional functions one-by-one.

Closely collaborate with the users to support new business processes.

Emphases on business processes and operability.

Use a collaboration platform for documentation, issue tracking, release management and version control.

Delivery philosophy


Online payments

Payment Web services

Autobilling

Credit Card Tokenizer

Float Manager

Reloads via SMS

Dashboard & Reporting

Reconciliation & Financial functions

Offline batch file uploads

Functionality


Online Payments, using payment methods:

Credit cards

Paypal

E-wallet

Bank Account

Online Payments


The following payment collection and reload channels can connect to Payment Exchange web-services to send payment notifications and perform reloads in real-time:

1. Postpaid payment channels

o Banks through Internet Banking, Mobile Banking, ATM

o Post Offices

2. Prepaid reload channels

o Banks

o Distributors

3. Web Portals

4. A trusted party with a smart device and financial service support

Payment Web services


In the case of postpaid payments for barred lines, other systems are required to operate in near real-time for the customer’s line to be unbarred immediately:

Upon receiving postpaid payment notifications, Payment Exchange notifies a credit management system (CMS)

CMS checks the updated credit status of the customer

CMS triggers an order management or provisioning system if the line can be re-activated

the release of the call bar is carried out

a text message is sent to the customer to inform him that his line has been re-activated.

Payment Web services: BSS actions


Payment Exchange supports real-time charging of credit cards or direct debit for invoices due for payment.

This is a Payment Exchange service offered to the BSS that replaces the file-based interface with the bank and provides better customer communication. It can be easily extended to support automated pre-paid reloads.

The necessary offline (no card-holder interaction), real-time credit card charging facility requires an acquiring bank.

The Payment Exchange offers APIs for autobilling enrolment that payment channels can integrate with. These API send the information received to the BSS which maintains the autobilling database.

Autobilling


The autobilling function is managed by:

Customer enrolling for the service by providing credit card details

Charging the credit card in real-time, this is initiated by the BSS that owns the invoice data

Sending a text status message to the customer

In the event of failure, the attempt to charge the credit card will be repeated for a further pre-configured number of times

Autobilling


The tokenizer provides a secure mechanism to store credit card data.

Tokenization of credit card data is a common strategy to reduce the scope of the PCI-DSS audit (a credit card industry compliance requirement). It replaces sensitive credit card number values with non-sensitive token values.

The tokenizer itself remains in the scope of the PCI-DSS audit, systems which only store non-sensitive info can be removed from the audit’s scope.

The tokenizer has clearly defined interfaces that are available to other authorized systems.

Credit Card Tokenizer


The Float Manager provides wallet and commission functionality for payment agencies which are required to maintain a float in order to sell products of the operator, such as prepaid distributors and dealers.

Any sale or payment collection done by the agency will be debited from their float (wallet) first. Commissions are credited back into the wallet in accordance with the agency’s commission plan.

The Float Manager can manage: Dealer and distributor balances The direct purchase of credit by distributors The subsequent transfer of credit from distributors to their

dealers and from dealers to sub-dealers The commission plans for the distributors and dealers

Float Manager


The Float Manager portal gives distributors and dealers access to information such as their credit balances, reload status, purchase orders, and relevant notices in near-real time.

Float Manager portal


Dealers can use a SMS platform to carry out pin-less prepaid reloads.

The flow is as follows: Once the dealer collects from the customer Dealer will SMS the order to reload credit to the customer Payment Exchange will debit the dealer balance, compute

the commission, and reply to the dealer The customer will receive his reload as well as a reload

notification

Reloads via SMS


Payment Exchange has dash-boarding and reporting functions, providing information such as:

Postpaid payments, postpaid-to-prepaid credit transfers, dealer payments and prepaid top-ups on an hourly basis

Payments on a daily basis and their performance over time

End-to-end processing times of various functions for the participating systems and the PG itself.

Payment Kiosk activity

Release Call Bar time

Float Manager-related information, such as dealer credit balances, reload status, purchase orders, and relevant notices in near-real time is provided to all concerned parties.

Dashboard & Reporting


Automatic data-reconciliation between agencies and the Payment Exchange, and generation of exception reports.

The financials are posted directly to the EAS.

Payment Exchange generates financial, audit and regulatory reports.

Reconciliation & Financial functions


Components

Adapters

Adapters

Business Logic

Payment Exchange Core R

epo

rts

Au

dit

ing

Credit Channels Debit Channels

EAS BSS ESB

Payment Exchange consists of the following components:

SOAP based web services support all credit transactions, including support for on-line payments by credit cards, PayPal and E‒wallet.

Debit channels such as credit cards and bank specific protocols are supported by adapters.

Adapters on the south side provide connectivity to the company’s internal systems. In the ideal case, the payment exchange only connects to the Enterprise Service Bus.

SOAP


The core of the Payment Exchange

o contains the logic to ensure the uniqueness of any transaction,

o holds the processing status of each transaction,

o includes the credit card tokenizer,

o maintains operational key data,

o provides centralized logging and

o contains the database functionality.

The Business Logic is implemented by dedicated Java classes with appropriate configuration options. This approach gives better maintainability and is highly cost-effective compared to a commercial Business Process Execution Engine.

GUI functionality for Reports and Reconciliation is browser-based.

Components


Payment Exchange integrates to ESB, BSS and EAS using Web services and communicating with SOAP operations.

The current SOAP operations available in the PG are:

1. ValidateAccount: this operation accepts either an account number or a service number (phone number).

2. QueryAccount: this operation retrieves some account balance information

3. MakePayment: this operation tells the backend system that the PG has accepted payment on behalf of the backend system

4. QueryMakePayment: in the event the PG does not receive a response from the backend system after the PG sends the “MakePayment” operation, this operation will be sent to find out the status of the previous “MakePayment” operation.

Backend Integration


5. ReversePayment: this SOAP operation is used to reverse any previously successful posting, if required

6. QueryReversePayment: in the event the PG does not receive a response from the backend system after the PG sends the “ReversePayment” operation, this operation will be sent to find out the status of the previous “ReversePayment” operation.

To support efficient business processes, connections to other relevant systems -like financial systems, charging systems, SMSC- can be implemented following these systems’ requirements.

Backend Integration


Programmed in Java

Axis for SOAP implementation

MySQL database server

Browser-based GUIs using GWT (Google Web Toolkit)

Apache / Tomcat web servers

Deployed on commodity hard-ware,

High Availability possible through MySQL cluster

Technical


Deployment

All servers are active and load balancers distribute the traffic over the proxies, application and DB servers.

A fully redundant and highly available and very scalable Payment Exchange system consists of pairs of proxy servers, application servers, online payment servers, database servers, database managers and two pairs of data nodes.


The orange-outlined boxes in the previous diagram are the load balancers. The following machines should be load balanced:

The reverse proxies in the DMZ

The application servers in the internal network

The DB servers in the internal network

There are two physical load balancers, one in the DMZ and one in the internal network. The load balancer in the internal network will be used to load balance both, the application servers as well as the DB servers. For redundancy, each LB should have a passive standby as the backup.

Deployment


Network architecture

New Payment Exchange Introduction · 2015. 5. 25. · In Commercial Confidence 26-May-15 Page 3...

Documents

Transcript of New Payment Exchange Introduction · 2015. 5. 25. · In Commercial Confidence 26-May-15 Page 3...