Payment Exchange. An introduction. 26-May-15. In Commercial Confidence

Size: px
Start display at page:

Download "Payment Exchange. An introduction. 26-May-15. In Commercial Confidence"

Transcription

1 Payment Exchange An introduction In Commercial Confidence 26-May-15

2 Topics Overview Functionality Components Deployment Page 2

3 Payment Exchange Introduction 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. Financial Mgmt System Postpaid Payments Autobilling Bill Presentment Prepaid Reloads E-Wallet Reloads Charges Postpaid Billing Prepaid IN E-Wallet Credit Card PayPal Bank Account Page 3

4 Introduction 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. Page 4

5 Business Benefits 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. Page 5

6 Operational 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. 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. Page 6

7 Delivery philosophy 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. Page 7

8 Functionality Online payments Payment Web services Autobilling Credit Card Tokenizer Float Manager Reloads via SMS Dashboard & Reporting Reconciliation & Financial functions Offline batch file uploads Page 8

9 Online Payments Online Payments, using payment methods: Credit cards Paypal E-wallet Bank Account Page 9

10 Payment Web services 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 Page 10

11 Payment Web services: BSS actions 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. Page 11

12 Autobilling 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. Page 12

13 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 Page 13

14 Credit Card Tokenizer 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. Page 14

15 Float Manager 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 Page 15

16 Float Manager portal 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. Page 16

17 Reloads via SMS 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 Page 17

18 Dashboard & Reporting 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. Page 18

19 Reconciliation & Financial functions 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. Page 19

20 Reports Auditing Components Credit Channels ESB SOAP Business Logic Payment Exchange Core Adapters BSS Debit Channels Adapters EAS 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. Page 20

21 Components 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. Page 21

22 Backend Integration 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. Page 22

23 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. Page 23

24 Technical 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 Page 24

25 Deployment 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. All servers are active and load balancers distribute the traffic over the proxies, application and DB servers. Page 25

26 Deployment 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. Page 26

27 Network architecture Page 27