Making of core banking system (CBS) or a payment engine

 

Doing anything sincerely in FinTech space will require a core banking system or a payment engine.  Making a core banking system or a payment engine is not just like making an API. It requires dedicated efforts in making the base of a transactional system on top of which you can make various peripheral service and applications.

When you make such a core system, then it should be aligned with the vision of the business. Some of the capabilities which almost all core banking will require is all types of supported payment collection or add balance transactions, and all types of payout/transfers. It needs to perform proper accounting of all types of transactions.

Following is more:

1. Account management: The core system should be able to manage customer accounts, including opening new accounts, updating account information, and performing account maintenance.
   
2. Transaction processing: The core system should be able to process various types of transactions, such as deposits, withdrawals, transfers, and bill payments.
   
3. Customer relationship management (CRM): The core system should provide tools for managing customer data and interactions, including customer profiles, preferences, and transaction histories.
4. Loans and credit management: The core system should be able to manage loan and credit applications, approvals, disbursements, and repayments.
5. Risk management: The core system should have risk management capabilities, such as credit scoring, risk assessment, and fraud detection, to help banks mitigate risk and prevent losses.
6. Integration: The core system should be able to integrate with other banking systems and applications, such as payment systems, treasury systems, and accounting software.
7. Reporting and analytics: The core system should provide comprehensive reporting and analytics capabilities, allowing banks to track transactions, monitor performance, and identify trends.
8. Security & Compliance: The core system must comply with regulatory requirements, such as KYC, AML, and Basel III, PCI DSS, to ensure that the bank meets industry standards and regulations.
9. Security: The core system should provide a secure platform for managing sensitive financial data and transactions, including encryption, authentication, and authorization tools.
10. Customer support: The payment engine should provide reliable and accessible customer support, including 24/7 helpdesk support, online resources, and user guides to help merchants resolve any issues or concerns.
11. Customization: The core system should allow for customization of payment forms and receipts to match the branding and messaging of the customers

 

 Author: Surender Kumar, CTO at iMoney Pay

How to stop UPI fraud with dynamic QR & intent URL

 

This post is for payment system application developers & product managers, online merchants, and anybody else who wants to understand how to protect against a UPI fraud.

There are various kind of tricks used by fraudsters to loot unaware users on internet. Following are some steps a payment system can do to protect the innocent users against UPI frauds.

• Dynamic QR: If payment system is generating a unique QR for each transaction with a condition that only one payment can be made against a QR, then it limits the fraudsters that they will not be able to re-use the same QR again and again.
  
  
• Dynamic Intent URL: As a payment system you can also generate a unique UPI intent URL for a unique transaction, this will also limit the fraudsters. A new kind of fraud pattern has been observed where user gets the impression that the user is getting payment via the intent flow, but actually the user is making the payment. This user only gets to know only after the amount gets deducted from the user's bank account. For example, the attacker makes a post on social media with an intent URL linked with an image, asking users to get cashback after tapping the image, rest is the story. If the intent URL can be used only once then the attacker will have to create many such posts, this limits the attacker
  
  
• As a payment system, you should also block all such merchants & customers who have done any kind of frauds, this way your payment system will not be an easy target for the fraudsters
  
  
• Permitting right mode (collect, QR, intent) of UPI transaction for a merchant only after understanding the use case of the merchant. For example, if use case of the merchant does not require collect flow, then do not allow the merchant to initiate a collect request
  
  
• Do not allow a push payment (payment via QR or Intent) which has not not been initiated by the payment system. For example, if UPI ID of the merchant on the payment system is merchantname@bankname then do not allow any one to push a payment on this UPI ID. It's better allow push payment only for the transactions initiated by your payment system. This will also help in reducing duplicate payments &  charge-backs. Will also help easy reconciliation of the payments
  

Feel free to comment about your understanding/question in this regards.

iMoney Pay provides these kind of solutions to protect the innocent users and merchants against frauds.

Author : Surender Kumar, Click to see his profile details and more such content

Transaction Success Rate | Security | Easy Payment Gateway Integration

 

Problem Statement:

• How can payment gateway integration impact online payment transaction success rate?
• How to integrate a payment gateway to achieve security, and transaction success rate?
• How can payment gateway integration make or break an online business?

Target Audience: Online Merchants, Payment Service Providers, Digital Payments Software Developers and Testers.

While integrating with a payment gateway, always focus on integration security, online payment transaction success rate, ease of integration and integration test-ability.

Security: Attackers can fraud online payments participants, be it online merchant, payment service provider or the buyer. You would want to know the following.

• Protection from man in the middle attack - Attackers use this attack pattern to exploit loopholes in payment integration. Here is another post of mine for providing details about this aspect.
• Passing un-required but sensitive information parameters in a web based transaction. For example a merchant is not supposed to pass hashing seed in the parameters when a buyer is redirected to payment page.
  
• Passing invalid parameters to payment gateway by merchant. For example refund amount more than captured amount. Always validate the fields before sending them to payment gateway.
  
• Transferring data in an unsecured/non-encrypted channel (eg. HTTP instead of HTTPS). It's must to use HTTPS.
  

Online Payment Transaction success rate: A failed online transaction is a direct business loss. It also adds to frustration of customer, makes the payment experience poor and the buyer may not want come again. It also adds to customer care issues. Know the following in this regards.

• A payment gateway may reject or invalidate a transaction if the merchant is sending invalid or un-required parameters. It also makes the message payload heavy and consumes more network bandwidth. Ideally, if possible, a payment gateway should attempt to correct invalid parameter. For example a payment gateway can ignore an optional but invalid value instead of rejecting the transaction. There can be various such ways to sanitize the parameter values.
• A merchant should make a server to server status inquiry when a buyer is not getting redirected to merchant system from PG in a defined time. It might happen that the buyer has paid but was not redirected to merchant because of some network issue. It would also reduce any duplicate payment related issues. Would make the buyer feel good because the buyer would get to know that the payment has been made and accepted by merchant else it leads to buyer feeling uneasy about the payment status.
  
• A Payment Gateway should send a notification to merchant system that the transaction has been successful. This makes it double sure that merchant system gets to know about success of the transaction. Usually this feature is optionally given by all payment gateways but sometimes merchants do not use the feature which creates other issues. The best way to send the notification is to call a restful API of merchant system to update that the payment has been successful failure
  
• A merchant should make status inquiry transaction, if there is a timeout in a particular transaction. For example, if merchant initiated a refund transaction but did not get response. Before invoking a duplicate refund, ideally the merchant should make a status inquiry to validate if the previous refund transaction was successful or not. Same might be applicable to a sale transaction.

 Ease of integration: Following are important steps for ease of integration.

• Integration specification documents - Integration specification documents has to be up-to date, clean, simple, full of examples and details. It's always better to provide examples for various scenarios, details of each parameters, flow diagrams, and information about integration kits in different programming languages.
• Plugins for popular e-commerce platforms - It's always better that the payment gateways always provide integration plugins for different e-commerce platforms like Magento.
• Integration kits in different programming languages - It's a must the the payment gateway provide integration kits in all different programming languages. Like Java, Python, Go, PHP, C#/.NET etc.
• Integration support - A payment gateway needs a team to give support the technical teams of merchants at the time of technical integration
  

Integration test-ability: Automation integration tests - Integration kits in different programming languages needs to have various test cases to cover various scenarios. For example - A positive/negative test case for validating the message hash. A test case for a failed transaction, a test case for a duplicate check, a test case for a fraud transaction, a test case with/without optional fields, a test case capturing an un-authorised transaction, a test case to initiate a refund against a not captured transaction etc.

Thanks for your read. Please comment if you liked my post or need more details.

Man in the middle attack – Protect online merchants & payment solutions

 

Problem Statement:

How to protect from man in the middle attack in the payment’s world?

How to integrate a payment gateway in a secure way?

Why payment gateways and online merchants need to validate hash?

Example: When a payment gateway returns response to merchant system that a transaction has FAILED, the man in middle changes the status of the transaction to SUCCESS while the message is on the way, merchant gets a transaction response with status as SUCCESS, and merchant delivers the product or service to attacker but the status of the transaction with payment gateway is FAILED.

What & How: An attacker can change content of a message when the message is on the way between two payment systems. This is an old but frequently exploited attack pattern. The above is a very basic example of such an exploit.

But you will ask me how the message can be changed when it’s secured with HTTPS encryption – It can be done without spending much time. There are different ways, mainly it captures the content of the message on the web-browser using some tools and changes the content. If you want to learn how to perform an attack, then you may want to search the internet for how to guides. It’s hard to perform such an attack in a server-to-server API call, but it’s easy in case the message is flowing through the web-browser. For example, an HTTPS POST redirect by payment gateway web-application to web-application of merchant.

If you need a protection for your online payment system or not? It’s not a question of If. It’s only a matter of time when the attacker targets you.

How to know if your system is already under attack: A very basic symptom of being a victim is that there are differences in transaction status at different payment systems found at the time of reports reconciliation. For example, a merchant would say that payment gateway returned SUCCESS for a transaction but payment gateway company status that they returned FAILED. This can be validated by comparing the logs or database of the merchant vs payment gateway. One hint is that such reconciliation issues will be found with transactions of higher amount only. But sometimes it can be much sophisticated.

What can a payment gateway or online merchant do to protect against man in the middle attack:

• Validate the message hash: All messages flowing through the payment systems can be validated by generating and validating hash. It’s a simple, effective way to protect. Just make sure that there is a unique seed for each client, and the seed is not supposed to be part of the message. Only the client and server must be aware of the seed at the time of generation and validation of the hash. Make sure that you are using a modern hashing algorithm.
• Change the hashing seed on regular interval: The hashing seed should be changed on regular intervals, may be quarterly. It should not be same for ever because sometimes it’s shared with other people without understanding the consequences. It’s like you change login password with banking systems.
• Perform a server-to-server API based inquiry: A merchant can perform a transaction status inquiry with payment gateway to be double sure of the transaction status before delivery of goods/services. A payment gateway should also perform a status inquiry (with payment processor/acquirer) before delivering a successful response to merchant. Such an inquiry should be a server-to-server call only. Almost all payment systems in the world support such inquiries. Such enquirers can be exposed through restful APIs or ISO 8583 messages.
• Reconcile your payment reports daily: A merchant must reconcile the payment reports on daily bases and should be vigilant of any mismatches. Similarly, a payment gateway should reconcile with up-stream payment solutions.
• Have positive & negative integration tests: The integration test suite must have positive and negative test cases to validate the hash. Such tests must be performed at the time of integration between two payment systems. Such test cases should also be documented in the integration specification documents and should also be part of the integration kit. The technical integration team must perform these tests before the client on-boarding is completed.
• Test invalid hash transactions on production on regular bases: One such production test case can also be set to regularly test if the hash is being validated properly.
• Be vigilant: While the above-mentioned steps can be performed but your information security is not limited to these steps. Being vigilant about what’s happening in the system and having a mind-set of security is must for protection against sophisticated attacks.

 

Thanks for your read. Don’t forget to comment if you need further information.

Kubernetes for Digital Payment and FinTech Solutions

 

Kubernetes can be a choice for Digital Payment and FinTech solutions. This post is mainly about problems Kubernetes can solve for digital solutions. Using Kubernetes can contribute to better payment transaction success rate.

Kubernetes is getting popular each day and it can be called as a cloud native platform for automating deployment, scaling, and management of containerized applications. It is a production grade container orchestration system. I am calling it as cloud native because all major cloud providers are providing Kubernetes as a service, it can also be deployed as an open source system on top of bare metal machines and virtual machines

Following are some popular Kubernetes as services.    

Google Kubernetes Engine

Azure Kubernetes Service

Amazon EKS

Amazon Kops

Open Source Kubernetes - Though it is not as a service. It can be used when you want to manage Kubernetes cluster on your own, if you are not sure that you want do this then best for you is to use Kubernetes as a service 

Following can be some benefits of using Kubernetes in digital solutions

Optimal Scalability & Reduced Infra Cost - Auto provisioning and de-provisioning of compute resources for application servers facilitates both auto scalability and reduced infra cost. Imagine that your payment gateway is being used for sales of a new phone launched at 11AM and a huge population wants to buy that phone. How would you scale your payment gateway for such kind of unpredictable traffic? Another use case can be performing EOD batch settlements, EOD communications to merchants, EOD batch reports, and processing of batch of transactions coming in files. With Kubernetes you can provision and schedule such work loads and you are not supposed to keep dedicated VMs incurring continuous cost to you

Security - Kubernetes can run on it's own network where services are not directly accessible from outside world. Clusters can can in a VPC, it can facilitate encryption in transit, can facilitate secure configurations, can facilitate SSL termination, and many other security options are possible. Please keep in mind that Kubernetes requires a learning curve and having only very basic understanding about Kubernetes can lead to security loopholes. So don't forget security tests, pear review and other security practices before going live in production. Clear understanding of how Kubernetes works would help lot in keep security intact

Fault Tolerance -  A missed payment is a missed business for your merchants/customers, and as a payment service provider you would never want to do. Kubernetes can instantly bring up a crashed service to make the service available. It can run redundant instances of services for fault tolerance and scale. Multi-zonal Kubernetes cluster can further help you achieve DR practices

Auto deployment and no down time - Kubernetes can automate deployment of services and it makes sure that while the deployment is happening the services are not down. It deploys new version of service while service existing traffic on old version and the starts giving load to the new version and then stop giving loads to old version and finally destroys the old version. If a deployment fails or something goes wrong then it can rollback to old version

How payment gateway can handle refresh and back button for better transaction success rate

Target audience for this post are payment gateway(or other payment solution) software developers. I am detailing how to handle the back/refresh button so that the the payment transaction gets successful.

This is typical problem which can occur in any web application, for example resubmitting a form can lead to creation of a duplicate order. These kind of issues pop up more when user has poor internet connection, slow server due to over load or other reasons etc

As a payment gateway software developer you must have placed a text like "Please do not refresh the page and wait while we are processing your payment". This is shown to customer while the payment is under process at various pages. If the customer attempts to refresh or back button then the payment might fail or there may be a duplicate payment. There can be other errors leading to bad user experience and loss of business to both merchant and payment gateway because of a failed transaction.

Following can be the scenarios where a back/refresh button can create a problem:

• Scenario 1 - Merchant to payment gateway - This is when a user is being redirected by a merchant from merchant web/mobile application to payment gateway page, this redirection is usually achieved by a POST from merchant to payment gateway system. This is usually the first step in the payment process
  
  
• Scenario 2 - Payment Gateway to Bank/3D Secure Page - This is when a payment gateway redirects the user via POST request from payment gateway to a bank (or third party) for 3D Secure page or net-banking page of a bank
  
  
• Scenario 3 - Bank to Payment Gateway - This is when a third party (like bank for 3D Secure Page or net-banking) redirects the user to payment gateway after completing authentication at the third patties end
  
  
• Scenario 4 - Payment Gateway to Merchant Website - This is when a payment gateway redirects a user using POST request from payment gateway to merchant website. This is usually the last step in the transaction flow indicating success or failure of the transaction to merchant system

Following I am giving some generic solutions to handle different kind/stages of refresh/back button

• Screen dim after sometime: You know that mobile phones and devices dim the screen after inaction of sometime and exactly at this time the user presses the back/refresh button. In your text put something like "This can take a few minutes". So that the user is having patience. Well, all users might not read it but it would help in certain cases
  
  
• Keep your page light weight and fast: Take minimum time in loading your page and do the processing fast in payment gateway so that the overall time required reduces to significant extent
  
  
• Use status inquiry where possible: Do not duplicate a transaction, just check database of the transaction already exists or you can also make use of status inquiry provided by almost all payment systems/processors
  
  
• Post/Redirect/Get Design pattern - Where ever possible try to use Post/Redirect/Get design pattern. By using three different pages for submission, processing and displaying result of an action
  
  
• Keeping a unique id in session - In certain cases you might want to keep a unique value in session variable and check if it is re-submission before processing a duplicate request, using this logic you can ignore second third re-submission
  
  
• Do not disable back/refresh button - Do not attempt to do some tricks to disable use of back/refresh button because. That is not the way to go because that violates user experience, all web-browsers do not support such tricks
  
  
• Keep making status inquiry - You can keep making regular short internal status inquiry to payment processor/bank in the back-end system and once you get a success flag for a transaction just send a server to server notification to merchant's return URL. This can be done even if the user closes the web-browser after completing the transaction and before returning to merchant web application
  
  
• Creating a duplicate payment transaction - Certain online merchants may want to even do a duplicate transaction in cases where status of the transaction is not clear, this can be done on configuration bases and can diff for different merchants. If there are two duplicate transactions then one of them can be reversed/refunded. While this kind of requirement may not be applicable to all merchants. This may introduce manual interventions in reversals/refunds etc. It can add value in certain cases by not missing a sale
  

The above mentioned steps can help a payment gateway but may not eliminate such cases because a payment gateway does not have full technical control over banks and other financial institutions involved in a payment transactions, and they might be displaying such page without required smartness inbuilt to support such scenarios.

Following are various other ways to keep the transaction success rate high:

Robust payment gateway integration

How to keep best database performance for a payment gateway

How smart payment page improves transaction success rate

Right messaging format for payment gateway integration

Thanks for reading. Feel free to comment

ISO 8583 vs Name / Value Pairs | Payment Gateway Integration Architecture

It is very important to choose the right payment gateway integration design pattern while developing a payment gateway. This is important because it can impact transaction success rate directly (click here to see why). For online card not present transactions, a name/value or key/value pair based messaging format is considered best for payment gateways because it can help in following ways:

A name value pair based message will look like (just an example):

AccessCode = '100GFTJ',
Amount = 10000,
TransactionType = 'AUTH'
Locale = 'en',
MerchTxnRef = 'myorderid01',
MerchantId = 'mymerchantId',
OrderInfo = 'my order description',
ReturnURL = 'RETURN URL of MERCHANT WEBSITE',
Version = '1'
Note: There can be many other fields like above, can depend on transaction type also

1. Loosely coupled because it provides a flexibility in changing client-server contract in future at server end without requiring the existing client to change integration related code
   
   
2. Simplification of the client-server contract because ISO 8583 requires a learning curve and many online merchants may not have that skill or time required to integrate
   
   
3. Similarity to other payment gateways because many big and popular payment gateways are using the same approach. This kind of similarity allows the clients to integrate with your payment gateway without much effort or additional learning curve
   
   
4. Test-ability ease with various scenarios and transaction types, you can run your existing old test cases to validate if the new code will not break any existing clients
   
   
5. Same messaging format with different transaction types, you can keep the URL also same because the client will not be required to change URL for different transaction types. Transaction type can be a name/value pair in the message like TXN_TYPE=AUTH

In case you are developing a payment gateway interface for card present/POS terminal based transactions then ISO 8583 is better because:

1. ISO 8583 is a light weight and compact messaging format, it makes the message size small all POS terminals may not be having a high internet bandwidth and speed to transfer big sized messages to servers
2. A client/merchant will not require a learning curve because offline merchants are provided the POS terminals by the payment gateway company or a technology partner

Click for a quick read about about payment gateway integration for best transaction success rate

Thanks for reading

12 Factor App Guidelines for Digital Payment Solutions

The 12 factor app guidelines have become an important baseline for horizontally scalable & robust microservices. They can also be used as baseline for microservices in digital lending platform or loan management system (LMS) or loan origination system or a payment gateway. These guidelines are particularly important for a financial software solution because you cannot afford to miss payments as a result of fragile technology, these guidelines also help to be more agile and quick in quality releases of new features and bug fixes.

 

Following I am giving a snapshot of the guidelines and a link to potential microservices in a payment gateway and the 12 factor guidelines

https://www.onlinepaymentsindia.com/2020/06/potential-micro-services-in-payment.html

https://12factor.net/

Thanks for reading

You are welcome to comment and share your understanding