How to build PaaS (Payment As A Service) a step to step guide
Hi All,
One more day one more blog on Payments :)
Before we move ahead pls check out my previous blogs on Payment domain so that few of the terminology which I use here will seems familiar
Today we will discuss what is required to create a Service like PaaS in house which will take the complete responsibility of powering payment options to the e-commerce platform and the modus operandi of payment transaction with its complete cycle.
Why PaaS?
When you are a startup you can choose to go with Payment Gateway Aggregators who can provide you complete package of payment options and different PG integrations behind the scene. It’s costly, bottleneck in the sense if the PG Aggregator goes down or feels shaky you don’t have control over it. But this is best when you don’t want to invest much from the tech bandwidth to overcome this module when there are several solutions available.
When you grow from startup to a reliable, sustainable business and looking for scale with international expansion also in mind then you might want to look into this module and you would like to have in depth knowledge of the payment system as well as “control”. Thus one time cost and tech bandwidth will be required to create a platform which can take care of all the demands which your e-commerce clients want and which also facilitates the direct and indirect PG aggregation at its core.
There is a very detailed newsletter by PWC on what are the benefits of having PaaS — https://www.pwc.in/industries/financial-services/fintech/dp/payments-as-a-service-paas-an-approach-to-outsourcing-the-payments-technology-and-support-functions.html
What PaaS Offers for Payment Service Provider?
PaaS or Payment As A Service is the one stop layer for the PG integrations and thus act as Wrapper Layer on top of all PG integrations. PaaS will integrate all the possible Direct PG, Wallets, PG Aggregators and have the backend ready with following features —
- Secure & Configurable Merchant Credentials (MID, Encryption Logic, Encryption Key etc)
- Server Side integration of PG Auth & Capture APIs
- Server Side integration of PG Cancel/Refund APIs
- Server Side integration of Get Payment Details APIs
- PaaS also provides the web hook call for any callback functionality for PG to respond with latest payment transaction status (if required)
- PaaS should whitelist the third party API end points for security POV
- PaaS should also have PCI — DSS Certification (Level 1–4 depending on your business scale) https://www.pcisecuritystandards.org/
What PaaS Offers for Merchants clients?
PaaS or Payment As A Service will provide the set of APIs to make online payment easier for the merchants and merchants can have their own look n feel plus they can have additional features of having different payment options to the users for their different clients (web/mobweb/apps).
- Get Payment Instruments API
- Start Payment Session API
- Get Payment Details API
- Cancel/Refund API
- Additionally you can add Get Wallet Balance API or Get Saved Cards API also based on your merchants need in the PaaS (optional)
1) Get Payment Instruments API
As a pre-requisite configuration you can ask what your merchant wants as payment instruments or payment options (CREDIT/DEBIT/NETBANKING/WALLET etc) to show in their payment page/screen. This should be stored in document store or config keeper service so that we can change it anytime as per the demand from merchant.
- This way the merchant can choose what all payment options it can have
- What is the priority of the Payment Gateways merchant wants to setup for CREDIT/DEBIT and NetBanking Options.
- Now the merchant can choose different order for the different payment instruments for its different channels for eg. website, mobile web and mobile apps.
This is a server to server call which gives you all the payment instruments which you have already saved in PaaS for the merchant in the user friendly JSON structure. This can be reordered and changed for different Channels of the merchant. Now merchant has the flexibility to add any payment options related to merchant in their UI for eg. COD and merchant can also have other features like Offers, Insurance or merchant Wallet in the same Payment screen which is non-online-payment-instruments.
You can use redis as Key Value Pair for configkeeper database which can store all the configuration for the payment instruments for each client for the merchant
2) Start Payment Session API
This call starts the payment session from merchant to the PaaS and creates a new payment_session_id at PaaS end for each payment transaction. This API can accept several parameters depending upon the requirement from merchant but my suggestion is must include the below 5 mandatory fields during this APIcall -
- Order Details — Order ID, Order Amount, Order Currency etc
- Customer Details — Customer ID, Email, Phone No etc
- URL Details — SURL, FURL and CURL are merchant Success, Failure and Cancel URLs where PaaS needs to return the control post payment transaction.
- Optional Params — UDF list and BPV list. UDF list will be used by PaaS for future cases called user defined values. BPV list will be used by merchant to by-pass any value from PaaS to Bank to merchant back without any alteration.
Output — a PaaS target URL with PaymentToken where merchant client will POST the data.
The merchant client will pass the card details in case of CREDIT or DEBIT or the Netbank option the customer has selected to PaaS. So there is a solution which most of the Payment Gateways use at client side to know the customer payment details (and which lies between 2 and 3 API calls)
This form POST can be triggered from either website, mobile web or mobile apps which gives the merchant flexibility to have native design and look and feel on the payment screen. Once the form is post to backend, Paas does the following —
- Verifies the Authenticatation and Authorize them to use the preferred PG for the Payment Details which has been submitted
- Cross verifies the order details in the form with backend data like Order Amount, Order currency etc.
- Redirects the flow to the 3D Secure page of the PG which then takes the user to the respective Bank screen for 2 Factor Authentication
3) Get Payment Details API
Once the actual payment transaction is completed at the Bank 3D Secure page the control flows back to the PG and from PG to the merchant based on the payment status whether it is Success/Failed/Cancelled.
This server to server call should be called from merchant SURL, FURL or CURL to know what actually happened to the payment transaction and what is the response from the Bank or PG to PaaS. With this call merchant can also check the payment status as well as the actual PG used by PaaS during that transaction as there may be a chance the PaaS had switched the PG dynamically for better success rates. The BPV (by-pass values) should also be a part of the response of this API call.
Output — Payment Status with PG used at PaaS and PG response info which includes pg_txn_id and bank_reference_number for that transaction
3) Cancel/Refund API
Late refunds are nightmare to any e-commerce organisation. You might try automatic refunds or manual bulk refunds but there are numerous corner case scenarios which needs to be handled in today’s world e-refunds.
I will broadly break down refunds into 4 parts -
- Auto Refunds (Need Tech Solution)
- Partial Refunds (Need Tech + Manual Solution)
- Manual Refunds (Need Man Power)
- PG Auto Refunds (null)
Before we jump into refunds lets understand what Payment Gateway requires to refund any amount -
- PG Transaction ID (pg_txn_id)
- Refund Amount (Should NOT be greater than purchase amount)
In a nutshell — Merchant sends the refund request to PaaS > Paas forwards the request to PG > PG recognises the order based on PG Transaction ID > PG initiates a refund request to the respective Bank for that payment transaction
AUTO REFUNDS
These are refunds where customer just initiates the cancellation and you cancel the order with cancellation charge and then your system takes care of refunding the amount. We should take the refund request asynchronously and push it to our refund queue which takes care of PG refunds + database system update (No man in the middle required) The below image is self explanatory -
We have producer which produces refund requests and consumers who are waiting for refunds requests to process (you can have multiple consumers depending upon your needs) Each refund request goes through 2 actions -
- Call PG Refunds/Cancel API using pg_txn_id
- Update the Success/Failure of refund into the System
In this solution we maintain a Success Queue and an Error/Failure Queue (if anything fails during the PG refund process). You can send an email with failure refunds if its NOT getting processed on X no. of trials.
From Tech Stack POV you can use either RabbitMQ, Kafka or SQS also for refund usecase.
PARTIAL REFUNDS : These refunds are totally based on PG where they support partial cancellation or NOT, like in any e-commerce if you allow the customer to cancel 2 out of 3 items purchased then partial refunds comes to picture. In such cases PaaS needs to call the PG 2 or 3 times depending upon customer requests. Partial refunds are totally controlled by PG as they may or may NOT allow partial refunds. You need to discuss this with PG before hand during the contract sharing & integration.
MANUAL REFUNDS : These are the refunds where you DO NOT have PG Transaction ID logged in your system for any reason OR your PG Refund APIs are failing every time OR your PG doesn’t support Partial Refunds. Big organisations keep a separate refunds team to process all such manual cases for CSAT(customer satisfaction). The team can manually take all the refund orders and push to PG console for “Bulk Refunds” or they can send the refunds with order number to PG team directly.
AUTO PG REFUNDS : We understand PG captures the payment transaction during Booking cycle, similarly PG auto refunds the payment if it is unsuccessful to provide the capture details to merchant. This happens duing booking/purchase cycle itself.
For eg. merchant requested for a transaction > PaaS forwards it to a PG > PG captured the payment taking the customer to Bank > Bank responded — money deducted to PG> but PG somehow couldn’t reach the merchant (network issue, timeout issue or merchant site was facing fluctuation etc)
In such cases if you have allowed “Auto Refund” with PG then they take the decision to “Auto Refund” automatically from their end itself. This has trust issues as you will never get to know what happened to the transaction either money was deducted or NOT if yes then what happened to actual money?
We are still working on making this process streamline but its better to share the findings..small but strong steps from Product + Tech will make sure the customer satisfaction increases, this in turn increases the credibility and finally the repeated customers for the growth of your organisation. That’s all for today. Feel free to share your love and comments to this blog.
Do read my medium blog on 10 simple tips to keep a check on payment success rates :)
Originally published at https://www.linkedin.com. Happy Building PaaS !!
